JP5957785B2 - Matter maintenance management device, matter maintenance management method, and matter maintenance management program - Google Patents

Description

  The present invention relates to a case maintenance management apparatus, a case maintenance management method, and a case maintenance management program.

  Programs used as business applications are updated on a daily basis as the business content changes. For example, a company's settlement application is subject to maintenance by a system engineer whenever there is a tax system revision, accounting rule revision, or the like. The term “maintenance” as used herein means a general change in program contents, and includes, for example, changing a part of an algorithm, changing an argument at the time of calling a method, and the like. Regarding application maintenance, “version management” is important in which an application used for which business is updated to which version, and which version can be applied to which business.

  Patent Document 1 describes an “application update processing system” and the like. According to Patent Document 1, a certain application is used by a plurality of servers, and a notification of an update request for the application is transmitted from a certain terminal device to a certain server. When the server fails to update, an update failure notification is returned to the terminal device. The terminal device that has received the update failure notification transmits an application update cancellation request notification to all servers. The server that has received the update cancellation request notification cancels the update of the application and restores the state before the update.

JP 2004-86769 A (paragraph 0012)

  As the application becomes larger, the application is composed of many modules. Each of the modules is a maintenance target. One module may be a part of a plurality of applications. In such a case, it is assumed that a certain module included in a certain business application is changed. Then, another business application having the changed module as a part of the configuration may not be operated or may not be affected at all. As described above, for the maintenance of an application module, “version management” for each module such as which module is updated to which version and which version guarantees the operation of the application is extremely important.

However, Patent Document 1 does not assume a case where an application is configured by a plurality of modules. Therefore, when the correspondence between a module and an application is many-to-many, it cannot be determined from the viewpoint of guaranteeing the operation of another application whether or not a certain module can be updated for a certain application.
Further, Patent Document 1 does not disclose a criterion for determining whether or not an application update fails. Therefore, a separate measure is required to determine whether or not the application can be updated by comparing the case where the application can be updated and the case where the application cannot be updated.
Therefore, an object of the present invention is to provide a case maintenance management apparatus that determines whether or not a module can be updated according to a predetermined standard when an application is composed of a plurality of modules.

The matter maintenance management device of the present invention deletes a module that has been updated in the latest matter that has already been completed out of matters, and the matter that is being operated based on the module that was updated in the matter immediately before the latest matter Accepts the request to update the module in the first update order starting from the previous matter and going through the latest matter to the matter in operation, reaching the latest matter starting from the previous matter and going through the matter in operation Whether or not it is possible to change to the second update order is determined by referring to the change pattern stored in the storage unit, and if the result of the determination is possible, the update history information It is characterized in that a record for a matter is deleted and a record for the matter being operated is stored.
Other means will be described in the embodiment for carrying out the invention.

  ADVANTAGE OF THE INVENTION According to this invention, when an application is comprised from a some module, it becomes possible to provide the case maintenance management apparatus which judges whether the update of a module is possible according to a predetermined | prescribed reference | standard.

It is a figure explaining the relationship between the case and module of this embodiment. It is a figure explaining the state by which the module of this embodiment is memorize | stored. It is a figure explaining the structure of the case maintenance management apparatus of this embodiment. (A) is a figure which shows an example of the matter module corresponding | compatible information of this embodiment, (b) is a figure which shows an example of the commit order information of this embodiment. It is a figure which shows an example of the update log information of this embodiment. It is a figure explaining the commit transition of this embodiment. It is a figure (continuation) explaining the commit transition of this embodiment. It is a figure which shows an example of the commit order change information of this embodiment. (A) is a figure which shows an example of the commit cancellation cost calculation information of this embodiment, (b) is a figure which shows the comparative example of the commit cancellation cost of this embodiment. (A) is a figure which shows an example of the item detailed information of this embodiment, (b) is a figure which shows an example of the item evaluation information of this embodiment. It is a figure which shows an example of the flowchart of the 1st process sequence of this embodiment. It is a figure which shows an example of the flowchart of the 2nd process sequence of this embodiment.

  Hereinafter, a mode for carrying out the present invention (referred to as “the present embodiment”) will be described in detail with reference to the drawings.

The relationship between the project and the module will be described with reference to FIG.
A project is a business generally performed in a company. Now, Project A is named “Financial Results”, Project B is named “Corporate Tax Tax”, and Project C is named “Property Tax Tax”. For simplicity, it is assumed that one application is used for one item. It is assumed that the application is also named “Financial Results”, “Corporate Tax Tax”, and “Property Tax Tax”.

  Normally, the “corporate tax payment” cannot be made because the annual profit of the company is not fixed unless the “financial settlement” is completed. If the “financial settlement” is not completed, the book value of the depreciable assets held by the company is not fixed, and therefore “asset tax payment” cannot be performed. In that sense, “financial results” and “corporate tax payments” are strictly related. Similarly, “financial results” and “property tax payment” have a strict prior relationship. On the other hand, “corporate tax payment” and “property tax payment” may be precedent to each other. This is expressed as “A <B = C” (detailed later).

  A module is a component of an application as described above. In the example of FIG. 1, there are five modules. They are “profit calculation” m1, “asset management” m2, “sales expense management” m3, “tax amount calculation” m4, and “bank transfer” m5. The application “financial settlement” includes a module “profit calculation” m1, a module “asset management” m2, and a module “sales expense management” m3. Similarly, the application “corporate tax payment” includes a module “profit calculation” m1, a module “tax amount calculation” m4, and a module “bank transfer” m5. The application “payment of asset tax” includes a module “asset management” m2, a module “calculation of tax amount” m4, and a module “bank transfer” m5.

  When the project A “financial settlement” starts, first, maintenance that reflects the tax system of the year is performed on the modules m1, m2, and m3. Immediately thereafter, it is tested whether or not the case A is executed without failure using the maintained modules m1, m2, and m3. If there is no problem in the test result, the actual “financial settlement” is performed after updating (commit) the modules m1, m2, and m3 after the maintenance.

  Similarly, when the case B “corporate tax payment” starts, first, maintenance that reflects the tax system of the year is performed on the modules m1, m4, and m5. Immediately thereafter, it is tested whether or not the case B is executed without any failure using the modules m1, m4, and m5 after maintenance. Now, paying attention to the module m1, the case A is updated once, and then the case B is being updated again. Therefore, in order to confirm whether the renewal will affect the case A (next year), it is also necessary to perform a combination test of the cases A and B. If there is no problem in the results of these tests, the actual “corporate tax payment” is performed after the modules m1, m4, and m5 after the maintenance are updated.

  Although detailed description of the repetition is omitted, similarly, in order to update the modules m2, m4 and m5 for the case C “payment of property tax”, not only the test for the case C but also the combination of the cases A, B and C It is a condition that the test is performed and there is no problem in the test result.

A state in which the module is stored will be described with reference to FIG.
The left side of FIG. 2 is the module m1. The module m1 is composed of main data and metadata. The main data is the program itself for “profit calculation”. The functions of the program of the module m1 are, for example, “sales expense period allocation” and “asset impairment processing”. The metadata includes an identifier (m1) that uniquely identifies the module, the name of the module, and the date on which the module was updated. When attention is paid to the update date, it can be seen that the module m1 is updated at the time of “20130105”, “20130110”, and “20130112”, and the three modules m1 updated at each time point are stored. The same applies to the module m2 (center of FIG. 2) and the module m3 (right of FIG. 2). Actually, the update time is finely managed not only by the date but also by the hour, minute, and second. However, only the date is shown here for the sake of simplicity.

  The configuration of the case maintenance management apparatus 1 will be described with reference to FIG. The case maintenance management apparatus 1 is a general computer. The case maintenance management device 1 includes a central control device 11, for example, an input device 12 such as a mouse and a keyboard, an output device 13 such as a display, a main storage device 14, an auxiliary storage device 15, and a communication device 16. . Each of these devices is connected to each other by a bus. The auxiliary storage device 15 stores matter module correspondence information 31, commit order information 32, update history information 33, commit order change information 34, commit release cost calculation information 35, matter detail information 36, and matter evaluation information 37 ( Both are detailed later). The auxiliary storage device 15 also stores a module 41 (symbol m1 and the like in FIG. 1).

The update history management unit 21 described in the main storage device 14 is a program. In the present embodiment, when the subject is described as “XX section is”, the central control device 11 loads the program from the auxiliary storage device 15 to the main storage device 14, and then the function of the program ( The details will be described later.
The case maintenance management device 1 is connected to the terminal device 2 via the network 3. Similarly, the terminal device 2 includes a central control device, an input device, an output device, a main storage device, an auxiliary storage device, and a communication device (not shown) connected to each other via a bus. There are usually a plurality of terminal devices 2, and a plurality of users maintain the module 41 via the terminal device 2. Of course, the user can also maintain the module 41 by directly operating the case maintenance management apparatus 1.

(Item module support information)
The case module correspondence information 31 will be described with reference to FIG. In the case module correspondence information 31, the module ID is stored in the module ID column 102 in association with the case ID stored in the case ID column 101.
The case ID in the case ID column 101 is an identifier that uniquely identifies the case.
The module ID in the module ID column 102 is an identifier that uniquely identifies the module.
For example, in the case of the case where the case ID is “A”, an application composed of three modules whose module IDs are “m1”, “m2” and “m3” in the case of the first line in FIG. It can be seen that is used. This is the relationship itself of the case A “final account”, the module m1 “profit calculation”, the module m2 “asset management”, and the module m3 “sales expense management” in FIG.

(Commit order information)
The commit order information 32 will be described with reference to FIG. In the commit order information 32, the standard commit order is stored in the standard commit order column 112 in association with the case ID stored in the case ID column 111.
The case ID in the case ID column 111 is the same as the case ID in FIG.
The standard commit order in the standard commit order column 112 is the order in which modules are updated, and is defined for a matter. “Standard” means that the order can be changed (details will be described later).

  The case ID “A” and the like correspond to “A” and the like in FIG. Then, in the records in the first to third lines in FIG. 4B, the module used for “financial settlement” is updated first, then the module used for “corporate tax payment” is updated, and finally, It will indicate that the module used for “property tax payment” should be updated. For example, the record on the first line does not determine in what order the modules m1, m2, and m3 are updated in the “financial account”.

(Update history information)
The update history information 33 will be described with reference to FIG. In the update history information 33, the date and time are stored in the date and time column 122 and the version is stored in the version column 123 in association with the history ID stored in the history ID column 121.
The history ID in the history ID column 121 is an identifier that uniquely identifies the record of the update history information 33.
The date / time in the date / time column 122 is the year / month / day / hour / minute / second when the record was created.
The version column 123 has small columns 123a to 123j having the module ID as a heading. Each of the small column 123a to the small column 123j stores a version. The version is a case ID (“A”, “B”, etc.) or a character string “org”. “Org” indicates that the module is in an initial state. “A” indicates that the module has been updated by being used for the case “A”.

When attention is paid to the record in the first line in FIG. 5, it can be seen that all modules are in the initial state at the date “20130105 10:00:00”.
Next, paying attention to the record in the second row, the module m1, the module m2, and the module m3 are updated by using the item “A” at the date “201310 110 10:00:00”, and the other modules are It can be seen that the initial state remains unchanged.
Further, when attention is paid to the record in the third row, it is understood that the module m1, the module m4, and the module m5 are updated by using the item “B” at the date “20130112 10:00:00”. It can also be seen that the modules m2 and m3 have not changed since the previous update, and the other modules are still in the initial state.

  Finally, paying attention to the record in the fourth row, it can be seen that the module m2, the module m4, and the module m5 are updated by being used for the case “C” at the date “20130115 10:00:00”. It can also be seen that the modules m1 and m3 have not changed since the previous update, and the other modules are still in the initial state.

  Changing the viewpoint, the sub-column 123a for the module m1 is viewed in the column direction. Then, it can be seen from the initial state that the module m1 is used for the case “A” and updated once, and then used for the case “B” and updated again. Although not directly understood from FIG. 5, the case maintenance management device 1 always stores the latest version “B” of the module m <b> 1 in the auxiliary storage device 15. Then, when the module m1 is updated next time, the latest version “B” of the module m1 is used as a reference. When the version “B” is used as a reference, the changed part is overwritten by the version “B”. For the part that has not been changed, the part of the version “B” is simply copied, so that a new version is created. Means that it will be created. In short, it means that version “B” is the source of the copy.

  The case maintenance management apparatus 1 may store the old version “org” of the module m1 and the old version “A” of the module m1 (see FIG. 2). However, the old version is rarely the source of the copy. Therefore, the case maintenance management apparatus 1 takes measures for cost reduction with respect to the old version. For example, the old version is stored in a specific area of the auxiliary storage device 15 having a relatively low maintenance cost, is not taken out as a cache in the main storage device 14, and is deleted when a predetermined time elapses. And storing as difference data only.

(Commit transition)
The commit transition will be described with reference to FIGS.
It is assumed that the case A has ended, the case B has also ended, and the time immediately before the case C ends. The update history information 33 is in the state shown in FIG. 6C after the state shown in FIG. 6A and the state shown in FIG. 6B. However, it is assumed that, for some reason, the module in the case B has not been updated, and there is a situation where it is desired to update the module in the case C.

  Such a situation is unlikely to occur in the examples of “financial results”, “corporate tax payment”, and “property tax payment” shown in FIG. Assuming that, in the case of “corporate tax payment”, module m5 has been updated on the assumption that there is no fee for the taxpayer to transfer the corporate tax (national tax) to the bank account. However, after that, in the case of “Property Tax Tax Payment”, it is possible that the taxpayer's fee for transferring the asset tax (local tax of the municipality where the asset is located) to the bank account will be different for each municipality. . In such a case, the motivation to cancel the module update in the case B, start the case C, and update the module used in the case C by using the module updated in the case A as a copy source. The question is whether this is possible.

  If it is possible, the update history information 33 transitions from the state of FIG. 6C to the state of FIG. That is, the record “H0003” is deleted, and the update of the module in the case B is cancelled. This is called “commit release”. In addition, the state of FIG.7 (d) is the same as the state of FIG.6 (b). Thereafter, when the module used in the case C is updated using the module updated in the case A as a copy source, the update history information 33 transitions to the state shown in FIG. Thereafter, when the module used in the case B is updated using the module updated in the case C as a copy source, the update history information 33 transitions to the state shown in FIG.

(Change standard commit order)
There are three criteria for determining whether it is possible to change the standard commit order. The first is the commit order change information 34 (FIG. 8), the second is the commit release cost calculation information 35 (FIG. 9A), and the third is the case detailed information (FIG. 10 (FIG. 10). a)).

(Commit order change information)
The commit order change information 34 will be described with reference to FIG. In the commit order change information 34, a change pattern is stored in the change pattern column 132 and an application flag is stored in the application flag column 133 in association with the pattern ID stored in the pattern ID column 131.
The pattern ID in the pattern ID column 131 is an identifier that uniquely identifies the change pattern (immediately described later).
The change pattern in the change pattern column 132 is a mathematical expression in which a plurality of project IDs are connected in series with equal signs (=) or inequality signs (<), and any change can be made to the standard commit order. Is shown.
The application flag in the application flag column 133 is information indicating that the change pattern is actually applicable, and is “◯” here.

  The change pattern will be described in more detail. In general, “A <B” indicates that the module used for the case B must be updated after the module used for the case A is updated. “A = B” indicates that the context of the update of the module used for the case A and the update of the module used for the case B is not questioned. “A <B = C” means “A <B” and “B = C”. “A <B” and “B = C” ”naturally leads to“ A <C ”. Now, we will use “→” to indicate the context of a project as “before → after”. Then, “A <B = C” allows “A → B → C” and “A → C → B”, while “B → A → C”, “B → C → A”, “C → “A → B” and “C → B → A” are not allowed.

(Commit release cost calculation information)
The commit release cost calculation information 35 will be described with reference to FIG. In the commit release cost calculation information 35, the post-update matter ID column 142 stores the post-update matter ID and the differential data amount column 143 contains the difference data in association with the pre-update matter ID stored in the pre-update matter ID column 141. The amount of work is stored in the work time column 144, the work wage column 145 stores the work wage, and the test cost column 146 stores the test cost.

The pre-update case ID in the pre-update case ID column 141 is a case ID of a case in which “a certain version” is used when another version is created using a certain version of the module as a copy source. “*” Will be described later.
The post-update matter ID in the post-update matter ID column 142 is a matter ID of a matter in which “other version” is used when another version is created using a version of the module as a copy source.
“*” Indicates that the module related to the case has already been updated and stored in the auxiliary storage device 15. The fact that “*” is not attached indicates that the module related to the case has not been updated, but the updated state can be known. The state in which the updated state can be known is, for example, a state temporarily stored in the main storage device 14 immediately before being stored in the updated state in the auxiliary storage device 15.

The difference data amount in the difference data amount column 143 is updated (scheduled) in the module specified (scheduled to be updated) in the item specified by the pre-update item ID and in the item specified by the updated item ID (updated). ) The data amount of the difference from the corresponding module. More specifically, this is the total data amount of the difference data amount between corresponding modules for all modules.
The work time in the work time column 144 is a time required for the user to create difference data in the case specified by the post-update matter ID.
The work wage in the work wage column 145 is a wage paid for the user creating differential data in the case specified by the updated case ID.
The test cost in the test cost column 146 is a test cost for the item specified by the updated item ID. Here, the test is a test of the subject matter alone, and is not a combined test including past matters.

Updating history management section 21 projects the maintenance management apparatus 1 projects A has been completed and the project B also completed, to create a record R ₁ in FIG. 9 (a). Both the module updated in the case A (based on “org”) and the module updated in the case B (based on “A”) are stored in the auxiliary storage device 15. . Accordingly, “*” is attached to “A” in the pre-change matter ID column 141, and “*” is also attached to “B” in the post-change matter ID column 142.

The update history management unit 21 creates the records R ₂ , R _3, and R ₄ in FIG. 9A after the case A is finished and the case B is finished, and immediately before the case C is finished. To do. At this time, both the module updated in the case A (based on “org”) and the module updated in the case B (based on “A”) are stored in the auxiliary storage device 15. It is remembered. Further, the module immediately before being updated in the case C is temporarily stored in the main storage device 14. Therefore, “*” is not added to “C” in the pre-change case ID column 141 and the post-change case ID column 142.

  Then, the update history management unit 21 divides the difference data when updating the module in which the change is made in the case C into two cases, based on “A” and based on “B”. The amount can be calculated. Similarly, the update history management unit 21 can calculate the difference data amount when the module is updated based on “C” in the case B to be repeated in the future. Further, the update history management unit 21 can determine the work time, the work wage, and the test cost (all assumed values) by multiplying the difference data amount by a predetermined conversion coefficient, for example.

  The modules used for case A, case B, and case C are as shown in FIG. 4A, and the standard commit order for case A, case B, and case C is as shown in FIG. 4B. Suppose there is. At this time, the cost of releasing the commit will be described with reference to FIGS. 9A and 9B.

(Assumption 1)
Note the first line in FIG. If Project A, Project B, and Project C progress as planned in that order, the final cost will be 300,000 yen (column 153) as the work wage and 600,000 yen (column 154) as the test cost. is there. These values, FIG. 9 of (a), the sum of the sum and testing costs of the work wage records R ₁ and record R _3. Similarly, the final difference data amount calculated is 3.0 MB (column 151), and the final work time is 30 hours (column 152). The cost from version “org” to version “A” is discarded (the same applies to assumption 2).

(Assumption 2)
Subsequently, attention is focused on the second line in FIG. Consider a case in which the case C is started after the case A is ended and the case B is also ended, the case B is not ended, the case C is ended, and then the case B is started again. The final cost is 220,000 yen (column 153) as the work wage and 440,000 yen (column 154) as the test cost. These values are the sum of the work wages and the test costs of the records R ₁ , R ₂ and the record R ₄ in FIG. 9A. Similarly, the final work time calculated is 22 hours (column 152). The final difference data is 1.2 MB (column 151). This value is 9 in (a), the sum of the differential data record _{R 2} and records _{R 4.} “1.0 MB” of the record R ₁ is erased and has no meaning to be added.

(Comparison between Assumption 1 and Assumption 2)
Comparing the records on the first and second lines in FIG. 9B, “Assumption 1” is disadvantageous from the viewpoint of cost and time. This is because updating the module used in case C with the module updated in case B as the copy source is different from updating the module used in case C with the module updated in case A as the copy source It means that there are many parts. Naturally, the difference is reflected in working hours, working wages and test costs.
From the viewpoint of the difference data amount, the final difference in the difference data amount between Assumption 1 and Assumption 2 is 3.0−1.2 = 1.8 MB, which is practically negligible. However, when this difference becomes enormous and is stored in a paid external resource, it cannot be ignored.

(Matter detailed information)
The case detail information 36 will be described with reference to FIG. In the case detailed information 36, in association with the case ID stored in the case ID column 161, the operation type column 162 has an operation type, the necessity type column 163 has a necessity type, and the priority level column 164 has a priority. However, the module number column 165 stores the number of modules, and the update count column 166 stores the update count.
The case ID in the case ID column 161 is the same as the case ID in FIG.
The operation type in the operation type column 162 is either “screen system” or “batch system”. “Screen system” indicates that the case affects the configuration of the screen visually recognized by the user, such as addition of a screen item. “Batch system” indicates that the item affects the batch processing, such as a change in the calculation method in the nighttime batch processing.

The necessity type in the necessity type column 163 is either “M” or “C”. “M” indicates that the case is necessary as a measure against a defect such as a bug. “C” indicates that the case is necessary for changing the specification of the business such as addition of a processing function accompanying the change of the system.
The priority in the priority column 164 is a character string indicating the priority of the case, and is “emergency”, “high”, “medium”, and “low” in descending order of priority.
The number of modules in the module number column 165 is the number of modules constituting the application used for the case.
The update count in the update count column 166 is the number of times the record of the update history information 33 (FIG. 5) has been newly created (updated) as a result of the case being executed in the past.
The “attribute” corresponds to an operation type, a necessity type, a priority, the number of modules, and the number of updates.

(Matter detailed information)
The case evaluation information 37 will be described with reference to FIG. In the case evaluation information 37, options are stored in the option column 172 and scores are stored in the score column 173 in association with the items stored in the item column 171.
The items in the item column 171 are classifications when the case is evaluated. The “operation type”, “necessity type”, “priority”, “number of modules”, and “update count” described in FIG. It is.
The choices in the choice column 172 are the values themselves stored in the respective columns 162 to 166 indicated by the items in FIG. 10A or the numerical range to which the stored values belong.
The score in the score field 173 is a partial point given to the item for the item. The score can be arbitrarily set by the user. The score is a measure indicating the importance of the project among a plurality of projects. A matter with a large score can be updated after deleting a matter with a small score even if a matter with a small score has been updated first.

The following can be understood by referring to the record of FIG.
(1) Operation type (1st and 2nd lines)
“Batch” cases do not always run immediately after testing. Therefore, the “batch system” has a lower score than the “screen system”.
(2) Necessity type (lines 3 and 4)
The case “M” is a case for healing a problem that the user is currently facing. Therefore, “M” has a higher score than “C”.
(3) Priority (5th to 8th lines)
Of course, the higher the priority, the higher the score.
(4) Number of modules (9th to 13th lines)
A large number of modules that make up a case means that the influence on other cases is great. Therefore, the larger the number of modules, the higher the score.
(5) Number of updates (lines 14-17)
A large number of update times of a matter means that a change request for the matter is large. Therefore, the higher the number of updates, the higher the score.

(Processing procedure)
Hereinafter, the processing procedure will be described. The “first processing procedure” in FIG. 11 uses the commit order change information 34 (FIG. 8) and the commit release cost calculation information 35 (FIG. 9A). The “second processing procedure” in FIG. 12 uses the commit order change information 34 (FIG. 8) and the case details information 36 (FIG. 10A). Each processing procedure determines whether or not commit cancellation is possible, and is in an alternative relationship.

The first processing procedure will be described with reference to FIG. It is assumed that the following assumptions 1 to 5 are established at the time when the first processing procedure is started.
(Premise 1) The case module correspondence information 31 (FIG. 4A), the commit order information 32 (FIG. 4B), and the commit order change information 34 (FIG. 8) are stored in the auxiliary storage device 15 in a completed state. It is remembered.
(Assumption 2) Project A and Project B have already been completed. Therefore, the update history information 33 (FIG. 5) is stored in the auxiliary storage device 15 in the state of FIG. 6 (c).

(Assumption 3) Project C is currently in progress, and module changes (not updates) and tests have already been completed. The changed module is temporarily stored in the main storage device 14.
(Premise 4) The user has found some defect in the module updated in case B. As a result, the user desires to update the version “C” based on the version “A” instead of updating the version “C” based on the version “B”.
(Assumption 5) The case maintenance management device 1 calculates the difference data amount, work time, work wage and the contents of the version “A *”, “B *”, “C” and test contents of the modules created so far. The test cost is calculated. As a result, the commit release cost calculation information 35 (FIG. 9A) is stored in the auxiliary storage device 15 in a completed state.
(6) The user can also work from a remote place using the terminal device 2. However, here, for simplification, it is assumed that the user is working using the case maintenance management apparatus 1.

(the term)
In order to simplify the explanation, the meaning of the meaning is defined as follows.
“Matter in operation” or “Matter in operation”: This is the matter that the user is currently operating and before the module is updated.
“Previous item” or “Previous item”: This item is desired to be used as a copy source when a user updates a module.
“Latest case” or “Latest case”: a case that appears for the first time in the latest record among the records of the update history information 33 stored at the present time.

  In step S201, the update history management unit 21 of the case maintenance management apparatus 1 accepts a request to update the module. Specifically, the update history management unit 21 accepts that the user inputs the request together with the previous case ID and the in-operation case ID via the input device 12. The in-operation item ID is the item ID of the in-operation item. The immediately preceding item ID is the item ID of the immediately preceding item. Here, the following description will be continued on the assumption that “A” is accepted as the previous matter ID and “C” is accepted as the in-operation matter ID.

In step S202, the update history management unit 21 determines whether or not module updates can be registered. Specifically, the update history management unit 21 first acquires the standard commit order corresponding to the previous case ID and the in-operation case ID from the commit order information 32 (FIG. 4B). Here, “1” is acquired for the immediately preceding case ID, and “3” is acquired for the in-operation case ID.
Secondly, the update history management unit 21 acquires the latest case ID from the update history information 33. The latest case ID is the case ID of the latest case. Here, “B” is acquired.

Thirdly, the update history management unit 21 determines whether or not all of the following conditions 1 and 2 are satisfied.
(Condition 1) The previous case ID matches the latest case ID.
(Condition 2) The standard commit order corresponding to the in-operation matter ID is immediately after the standard commit order corresponding to the immediately preceding matter ID.
Here, “condition 1” is not satisfied (A ≠ B), and “condition 2” is not satisfied (“3” is not immediately after “1”).
Fourthly, the update history management unit 21 proceeds to step S207 when the determination result is “satisfy all conditions” (step S202 “YES”), and otherwise (step S202 “NO”). The process proceeds to step S203.

In step S203, the update history management unit 21 determines whether the commit order can be changed. Specifically, the update history management unit 21 first acquires the change pattern of the record in which the application flag is stored from the commit order change information 34 (FIG. 8). Here, “A <B = C” is acquired.
Secondly, the update history management unit 21 determines that the change pattern acquired in “first” in step S203 sets the previous case ID as “first”, the in-operation case ID as “after”, and the latest case ID as “its” Further, it is determined whether or not the order relation (in this case, “A → C → B”) is allowed. Here, “A <B = C” allows “A → C → B”.
Thirdly, the update history management unit 21 proceeds to step S204 when the determination result is “permitted” (step S203 “YES”), and otherwise (step S203 “NO”). The process proceeds to S208.

In step S204, the update history management unit 21 calculates a commit release cost. Specifically, the update history management unit 21 first creates a first update order when commit release is not executed based on the update history information 33 and the in-operation matter ID. Now, the version “A” is stored in the second line of the update history information 33 (the state shown in FIG. 6C), the version “B” is stored in the third line, and the in-operation case ID is stored. Is “C”. Therefore, the first update order “A → B → C” is created.
Secondly, the update history management unit 21 creates a second update order in the case of executing commit release based on the immediately preceding case ID, the in-operation case ID, and the latest case ID. Here, the second update order is “immediate item ID → latest item ID ×, immediately preceding item ID → operation item ID → latest item ID” = “A → B ×, A → C → B”. “X” is the version to be released.

Thirdly, the update history management unit 21 uses the method described above in the description of FIGS. 9A and 9B to obtain final difference data for both the first update order and the second update order. Calculate quantity, work time, work wage and test cost. Here, the calculation result is as shown in FIG.
Fourthly, the update history management unit 21 calculates a determination value that is a result of subtracting the second comparison value (immediately described later) from the first comparison value (immediately described later).

The update history management unit 21 can select the following value as the first comparison value.
(1): Final work wage for the first update order (2): Final test cost for the first update order (3): Final work time for the first update order (4 ): Final difference data amount for the first update order (5): Amount obtained by multiplying the value of (3) by a predetermined conversion factor (6): A value of (4) is multiplied by a predetermined conversion factor Amount of money (7): At least two of the values of (1), (2), (5), and (6). What value is the update history management unit 21 as the second comparison value? The same applies to whether or not can be selected.

  In step S205, the update history management unit 21 determines whether the determination value is greater than or equal to a threshold value. Specifically, the update history management unit 21 proceeds to step S206 if the determination value calculated in “fourth” in step S204 is equal to or greater than a predetermined threshold (step S205 “YES”), and otherwise. (Step S205 “NO”) proceeds to Step S208.

  In step S206, the update history management unit 21 releases the commit. Specifically, the update history management unit 21 deletes the record related to the latest case ID from the update history information 33. Then, the update history information 33 transitions from the state of FIG. 6C to the state of FIG. Further, the update history management unit 21 deletes the module itself related to the latest case ID from the auxiliary storage device 15.

In step S207, the update history management unit 21 performs a commit. Specifically, the update history management unit 21 first searches the case module correspondence information 31 (FIG. 4A) using the in-operation case ID as a search key, and acquires the module ID of the corresponding record.
Secondly, the update history management unit 21 creates a new record of the update history information 33 (FIG. 5).
Thirdly, the update history management unit 21 stores the in-operation case ID in the sub-column having the module ID acquired in “first” of step S207 as the heading among the sub-columns of the version column 123 of the new record. To do. The other sub-column stores the version of the immediately preceding record.
Fourthly, the update history management unit 21 stores the newly assigned history ID and the current year / month / day / hour / minute / second in the history ID column 121 and the date / time column 122 of the new record, respectively. At this stage, the update history information 33 is in the state shown in FIG.
Fifth, the update history management unit 21 creates a module related to the in-operation case ID using the module related to the immediately previous case ID as a copy source, and stores it in the auxiliary storage device 15. Thereafter, the processing procedure ends.

  In step S208, the update history management unit 21 outputs an error message. Specifically, the update history management unit 21 displays the message “Commit order cannot be changed” on the output device 13. Thereafter, the processing procedure ends.

The second processing procedure will be described with reference to FIG. It is assumed that the above-mentioned “Premise 1”, “Premise 2”, “Premise 3”, “Premise 4”, and “Six” are established when the second processing procedure is started. It is assumed that the following “Premise 7” is satisfied instead of the above “Premise 5”.
(Assumption 7) The detailed case information 36 (FIG. 10A) and the case evaluation information 37 (FIG. 10B) are stored in the auxiliary storage device 15 in a completed state.

  The first processing procedure (FIG. 11) and the second processing procedure (FIG. 12) share steps S201 to S203 and S206 to S208. Therefore, hereinafter, only steps S204b and S205b which are changed portions will be described.

In step S204b, the update history management unit 21 calculates the total number of items. Specifically, the update history management unit 21 first searches the case detail information 36 (FIG. 10A) using the case ID being operated as a search key, and acquires the corresponding record.
Second, the update history management unit 21 searches the item evaluation information 37 (FIG. 10B) using the column headings and the values of the columns of the records acquired in “first” in step S204b as search keys. Then, the score of the corresponding five records is acquired. And the acquired score is totaled and it is set as the 1st total score. Since the in-operation item ID is “C”, the total score is “1 + 2 + 2 + 1 + 3 = 9”.

Thirdly, the update history management unit 21 searches the detailed case information 36 (FIG. 10A) using the latest case ID as a search key and acquires the corresponding record.
Fourthly, the update history management unit 21 searches the item evaluation information 37 (FIG. 10B) using the column headings and the values of the columns of the records acquired in “third” in step S204b as search keys. Then, the score of the corresponding five records is acquired. And the acquired score is totaled and it is set as the 2nd total score. Since the latest case ID is “B”, the second total score is “2 + 3 + 3 + 1 + 3 = 12.”
Fifth, the update history management unit 21 subtracts the second total score from the first total score, and sets the result of the subtraction as a “total score difference”. At this time, the difference in the total score is “9−12 = Δ3”.

In step S205b, the update history management unit 21 determines whether or not the total score difference is equal to or greater than a threshold value. Specifically, the update history management unit 21 proceeds to step S206 if the “difference in total score” in “fifth” in step S204b is greater than or equal to a predetermined threshold (step S205 “YES”), otherwise In the case (step S205 “NO”), the process proceeds to step S208.
Here, it is assumed that the predetermined threshold is “0”. Then, since “Δ3 <0”, the update history management unit 21 proceeds to step S208. This indicates that the importance of the case B is greater than the importance of the case C, and the case C cannot release the module update in the case B (the case C cannot overtake the case B). .

(Combination of the first processing procedure and the second processing procedure)
In the first processing procedure, the update history management unit 21 may execute step S204b of the second processing procedure immediately after step S205 “YES”, and then immediately execute step S205b of the second processing procedure. .

(Effect of embodiment)
This embodiment produces the following effects.
-Whether or not it is possible to cancel the update of the updated matter and update the matter that is being operated on for the update order of modules between multiple matters that use an application consisting of multiple modules Easy to judge.
・ Comparing the cost of updating the matter being operated based on the updated matter and the cost of updating the matter being manipulated based on the matter updated immediately before the updated matter In addition, the determination can be made.
It is possible to make the above determination after comparing the importance of the updated case with the importance of the case being operated.

In addition, this invention is not limited to an above-described Example, Various modifications are included. For example, the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. Further, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. Further, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.
Each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit. Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor. Information such as programs, tables, and files that realize each function can be stored in a recording device such as a memory, a hard disk, or an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.
In addition, the control lines and information lines are those that are considered necessary for the explanation, and not all the control lines and information lines on the product are necessarily shown. In practice, it may be considered that almost all the components are connected to each other.

1 Project maintenance management device 2 Terminal device 3 Network 11 Central control device (control unit)
12 Input device 13 Output device 14 Main storage device (storage unit)
15 Auxiliary storage device (storage unit)
16 Communication Device 21 Update History Management Unit 31 Case Module Corresponding Information 32 Commit Order Information 33 Update History Information 34 Commit Order Change Information 35 Commit Release Cost Calculation Information 36 Case Detail Information 37 Case Evaluation Information

Claims (7)

For each of a plurality of modules constituting a plurality of applications, update history information in which a version indicating which module is updated by an operation in a plurality of cases executed by the application is stored in time series,
When changing the order in which the matter is executed, a change pattern indicating a possible post-change order,
A storage unit for storing
The module updated in the latest case that has already ended among the cases is deleted, and the module is updated in the case being operated based on the module updated in the case immediately before the latest case. Accepts requests for
The first update order starting from the previous case and passing through the latest case to the current case, and the second update order starting from the previous case and passing through the current case to the latest case. To determine whether or not it is possible to change to, by referring to the change pattern,
If the result of the determination is possible, in the update history information, a record for the latest case is deleted and a control unit that stores a record for the case being operated;
A case maintenance management device comprising: The storage unit
The cost for updating the module in another matter based on the module updated in a matter is stored as the commit release cost calculation information stored for each combination of the matter and the other matter. ,
The controller is
Refer to the commit release cost calculation information,
Calculating a difference between a total amount of cost for executing the plurality of cases according to the first update order and a total amount of cost for executing the plurality of cases according to the second update order;
Determining whether it is possible to change the first update order to the second update order according to the magnitude relationship between the calculated difference and a predetermined threshold;
The item maintenance management device according to claim 1. The cost is
Including at least one of a differential data amount, work hours, work wages, and test costs;
The item maintenance management apparatus according to claim 2. The storage unit
Detailed item information in which a plurality of attributes of the item are stored in association with the item;
Item evaluation information in which a score indicating the importance of the item is stored in association with each value of the plurality of attributes;
And store
The controller is
With reference to the case details information and the case evaluation information, based on the attributes of the case being operated, the total value of the points of the case being operated is obtained, and further based on the attributes of the latest case , Get the total value of the points of the latest deal,
Calculate the difference between the total value of the acquired item in the operation and the total value of the acquired latest item,
Determining whether or not the first update order can be changed to the second update order based on the magnitude relationship between the calculated difference between the total values and a predetermined threshold;
The item maintenance management device according to claim 1. The attribute is
Including at least one of the operation type of the item, the necessity type of the item, the priority of the item, the number of modules constituting the application that executes the item, and the number of updates of the item,
The case maintenance management apparatus according to claim 4. The storage unit
For each of a plurality of modules constituting a plurality of applications, update history information in which a version indicating which module is updated by an operation in a plurality of cases executed by the application is stored in time series,
When changing the order in which the matter is executed, a change pattern indicating a possible post-change order,
And store
The control unit
The module updated in the latest case that has already ended among the cases is deleted, and the module is updated in the case being operated based on the module updated in the case immediately before the latest case. Accepts requests for
The first update order starting from the previous case and passing through the latest case to the current case, and the second update order starting from the previous case and passing through the current case to the latest case. To determine whether or not it is possible to change to, by referring to the change pattern,
If the result of the determination is possible, deleting the record for the latest case in the update history information and storing the record for the case being operated;
An item maintenance management method for an item maintenance management device comprising the storage unit and the control unit. For the storage unit of the case maintenance management device
For each of a plurality of modules constituting a plurality of applications, update history information in which a version indicating which module is updated by an operation in a plurality of cases executed by the application is stored in time series,
When changing the order in which the matter is executed, a change pattern indicating a possible post-change order,
Store
For the control unit of the case maintenance management device,
The module updated in the latest case that has already ended among the cases is deleted, and the module is updated in the case being operated based on the module updated in the case immediately before the latest case. Accepts requests for
The first update order starting from the previous case and passing through the latest case to the current case, and the second update order starting from the previous case and passing through the current case to the latest case. To determine whether or not it is possible to change to, by referring to the change pattern,
If the result of the determination is possible, in the update history information, delete the record for the latest case, and execute a process of storing the record for the case being operated.
A matter maintenance management program for causing the matter maintenance management device to function.

Images