JP2009169724A - Maintenance support device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently manage the update history of a program file in maintenance operation of a task system. <P>SOLUTION: A maintenance support device 100 receives an improvement request to a business system 200 under operation. An operator corrects a program file in response to an improvement request by a terminal 206 for development. The corrected program file is registered in a correction program storage part 164. The maintenance support device 100 detects a difference prior/posterior to correction as a correction place, and registers the improvement request and the correction place in association in a correction place storage part 166. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to maintenance of a business system, and more particularly to a technique for managing an update history of files constituting the business system.

  Business systems that support the operation of companies and public facilities, so-called enterprise systems, are now being introduced as the foundations of large and small organizations. The business system aggregates, accumulates, analyzes, and processes data obtained from node terminals and databases, and outputs information with higher added value. The number of program files that make up a business system may reach hundreds of thousands and sometimes millions. Business systems continue to evolve to make more complex organizational management more efficient.

Since such a business system continues to operate for many years, it requires various maintenance work such as operation monitoring, failure response, function expansion / change / decommissioning even after operation.
JP 2007-265029 A

In the maintenance work, it is important to manage the update history such as which code of which program file is modified at what timing and for what purpose. Generally, when some improvement request is proposed and the operator corrects the program file, the administrator extracts the difference between the program file before correction and the program file after correction. Then, after confirming that the code unrelated to the improvement request is not mixed in, the modified program file is released as a new version. Also record what modifications were made at each release.
However, as the number of program files included in a business system increases, the workload for accurately managing the update history of program files is becoming enormous.

  Furthermore, in recent years, maintenance work is often outsourced to programmers overseas such as China, Taiwan, India, and Russia. As many programmers with different backgrounds such as languages and skills are involved in maintenance work, a mechanism for more strictly and efficiently managing what code has been added during the maintenance work has become necessary. .

  The present invention has been completed based on the above-mentioned problem recognition of the present inventor, and its main purpose is to provide a technique for efficiently managing the update history of a program file during maintenance work of a business system. There is to do.

One embodiment of the present invention relates to a maintenance support apparatus.
This apparatus first receives an improvement request for an operating business system. When any program is modified in response to any improvement request, the difference between the modified program and the unmodified program is detected as a modified location, and the modified location is the trigger for the modification. Corresponding to the improvement request.

  It should be noted that any combination of the above-described components, and the present invention expressed by a method, system, recording medium, and computer program are also effective as an aspect of the present invention.

  According to the present invention, it becomes easy to manage the update history of a program file during maintenance work of a business system.

FIG. 1 is a hardware configuration diagram showing the relationship between the business system 200, the maintenance support device 100, and the development system 250.
The business system 200 shown here is a system introduced for business management of organizations such as companies and public facilities. The business system 200 may be configured as a system that integrates a plurality of geographically dispersed organizations. Here, a business system of an Internet securities company will be described as an example.

  The business system 200 is connected to employee terminals 202a, 202b,... 202c (hereinafter simply referred to as “employee terminal 202”) via an intranet or the like. The employee terminal 202 is a terminal used by an employee of an Internet securities company. Each employee accesses the business system 200 via the employee terminal 202 and performs daily work. Not only the employees but also workers of the management company may operate the employee terminal 202. However, in order to simplify the explanation, only the employee uses the employee terminal 202 in this embodiment. explain.

  The business system 200 is also connected to the development system 250 via the Internet or the like. The development system 250 is in charge of correction and update (release) of the program constituting the business system 200. The development system 250 includes development terminals 206a, 206b,... 206c (hereinafter simply referred to as “development terminal 206”), a release version holding unit 252 and a correction program holding unit 254. The development terminal 206 is a terminal used by a worker who performs maintenance work of the business system 200, for example, a programmer of an external maintenance management company. In recent years, many system integrators have promoted so-called offshore development. For this reason, the worker here is assumed not only domestic but also an overseas programmer. The release version holding unit 252 holds the same program as that constituting the current business system 200, that is, a release version program. The correction program holding unit 254 is a program in which a necessary modification is made to the released version program, and holds a program that is scheduled to be released in the future.

  The development system 250 is connected to the maintenance support apparatus 100 via a dedicated line or the like. The maintenance support device 100 is a device for supporting maintenance work of the business system 200. The maintenance support apparatus 100 is introduced in order to efficiently manage the update history of the program file that constitutes the business system 200. The maintenance support device 100 is also connected to the manager terminal 204 via a dedicated line or the like. The administrator terminal 204 is a terminal used by the administrator of the business system 200. The administrator accesses the maintenance support apparatus 100 via the administrator terminal 204 and supervises maintenance work by the worker. The maintenance support device 100 in this embodiment is operated via the administrator terminal 204.

  The maintenance support apparatus 100 includes a request holding unit 162, a correction program holding unit 164, a correction location holding unit 166, an update history holding unit 168, and a release version holding unit 169. In this embodiment, employees, workers, and managers are involved in maintenance work. Before describing specific functions of the maintenance support apparatus 100, first, an overview of the flow of maintenance work in the present embodiment will be given.

  R1: The employee uses the business system 200 on a daily basis through the employee terminal 202.

  R2: When using the business system 200, the employee notifies the administrator of points to be improved regarding the business system 200. It may be an indication of a defect, a proposal for improvement of a user interface or the like, or a proposal for adding a function such as trailing stop. This notification may be notified from the employee terminal 202 to the administrator terminal 204 by known communication means such as e-mail. Hereinafter, the notification of points to be improved in R2 is referred to as “improvement request”. When requesting improvement, various accompanying information such as employee name, proposal date and time, and urgency may be notified.

  R3: The manager transmits the improvement request received from the employee to the maintenance support apparatus 100. The improvement request transmitted from the administrator terminal 204 is registered in the request holding unit 162 of the maintenance support device 100. When an improvement request is registered in the request holding unit 162, a “request ID” is assigned as an ID for uniquely identifying the improvement request. The improvement requests registered in the request holding unit 162 are displayed as a list on the development terminal 206. A specific display mode will be described later in relation to the improvement request list screen 170 in FIG.

  R4: The worker refers to the improvement request list screen 170 and starts correcting the program file. First, the operator acquires the same program file as the release version from the release version holding unit 252. The operator makes necessary corrections on the acquired program file at the development terminal 206. In this way, a concrete response is made to the improvement request generated in R2. If necessary, a plurality of program files may be modified for one improvement request. The operator tests the program file after correction (hereinafter referred to as “modified program”, the program file before correction is referred to as “uncorrected program”) by itself and confirms the operation. And registered in the correction program holding unit 254. The operator registers the corrected version program and the request ID in association with each other in order to clearly indicate which improvement request is the correction. In order to officially release this modified version program, it is necessary to receive various operation tests such as integration test and comprehensive test by the administrator, and approval of the modification content by the administrator. Here, it is assumed that a certain program A is corrected.

  R5: The corrected version program A registered in the correction program holding unit 254 is transmitted to the maintenance support apparatus 100 together with the request ID. This modified version program A is registered in the modification program holding unit 164 of the maintenance support apparatus 100 together with the request ID. Here, the release version holding unit 169 of the maintenance support apparatus 100 also holds the same program file as the release version, like the release version holding unit 252 of the development system 250. The maintenance support apparatus 100 detects a difference between the uncorrected program A, that is, the program A held in the release version holding unit 169 and the corrected version program A newly registered in the correction program holding unit 164 as a corrected part. To do. Let the correction location at this time be “a”. The correction location a is associated with the request ID and registered in the correction location holding unit 166 of the maintenance support device 100. In this way, with the request ID as a key, which program is modified with respect to the improvement request, and further, which part of the program is modified is associated.

  R6: The administrator refers to the correction location a of the program A and the proposed improvement request and confirms on the screen whether the correction is necessary and useless. The administrator performs various operation tests called integration tests and comprehensive tests, and confirms the operation of the modified version program A. When the validity of the correction content is confirmed, the administrator inputs approval information via the administrator terminal 204 (hereinafter, such input is referred to as “approval input”). Each improvement request is associated with a completion flag. When an approval input is made, the completion flag is changed to “corresponding”. By this completion flag, an unsupported improvement request is distinguished from a supported improvement request. In this way, in the modified version program A modified on the development system 250 side, the modification content of the modification location a is approved by the administrator.

  When the revised version program A is officially released, the maintenance support apparatus 100 confirms that the contents of the revised version program A on the development system 250 side and the approved revised version program A on the maintenance support apparatus 100 side match. Check. Normally, they match, but in R5, after uploading the modified version program A from the development system 250 to the maintenance support apparatus 100, the operator may have further modified the modified version program A in the modified program holding unit 254. Absent. If the release is permitted without performing such confirmation, the correction b that the administrator does not know is reflected in the business system 200. In order to avoid such an inconvenience, as a final check before release, the modified version program A in the modified program holding unit 254 of the development system 250 is changed to the modified version program A in the modified program holding unit 164 of the maintenance support apparatus 100. It is necessary to confirm that the content is the same. If the modified version program A on the development system 250 side matches the modified version program A on the maintenance support apparatus 100 side, the maintenance support apparatus 100 releases the modified version program A at least if there is no substantial code change. The development system 250 is notified of permission.

R7: The development system 250 registers the modified version program A stored in the modified program storage unit 254 in the release version storage unit 252 on condition that the release permission notification is received from the maintenance support apparatus 100. The program A newly registered in the release version holding unit 252 is reflected as an official program constituting the business system 200.
Thus, the improvement request raised from the business site is reflected as a function of the business system 200.

FIG. 2 is a functional block diagram of the maintenance support device 100.
Each block shown here can be realized in hardware by an element such as a CPU of a computer or a mechanical device, and in software it is realized by a computer program or the like. Draw functional blocks. Therefore, those skilled in the art will understand that these functional blocks can be realized in various forms by a combination of hardware and software.

The maintenance support device 100 includes a user interface processing unit 110, a data processing unit 150, and a data holding unit 160.
The user interface processing unit 110 is responsible for user interface processing with workers, managers, and the like (hereinafter simply referred to as “users”). The user interface processing unit 110 displays various screens in the web page format on the administrator terminal 204 or the development terminal 206. The data processing unit 150 executes various data processing based on data acquired from the user interface processing unit 110 and the data holding unit 160. The data processing unit 150 also serves as an interface between the user interface processing unit 110 and the data holding unit 160. The data holding unit 160 is a storage area for holding various data.

User interface processing unit 110:
The user interface processing unit 110 includes an input unit 112 and a notification unit 130. The input unit 112 detects various user inputs to the administrator terminal 204 and the development terminal 206. The notification unit 130 displays various information on the administrator terminal 204 and the development terminal 206.

The input unit 112 includes a request reception unit 114, a correction reception unit 116, an approval detection unit 118, a version setting unit 120, and a selection unit 122.
The request receiving unit 114 receives an improvement request from the administrator terminal 204 in relation to R3. In addition to the text data indicating the content of the improvement request, the improvement request may include accompanying information such as the name of the employee of the proposal source, the urgency level, the importance level, and the proposal date. The improvement request is registered in the request holding unit 162 in association with the request ID. The correction receiving unit 116 receives the request ID and the corrected version program from the development system 250 in relation to R5. The modified version program is registered in the modified program holding unit 164 in association with the request ID. The approval detection unit 118 detects an administrator's approval input. The business system 200 manages the update history by version. The version setting unit 120 detects an input by an administrator for setting a relationship between a future version and an improvement request to be dealt with in order to release the version. The version setting will be described later in relation to the version setting screen 180 in FIG.

  The selection unit 122 detects various inputs by the user for confirming the update history of the version of the business system 200. The selection unit 122 includes a version selection unit 124, a request selection unit 126, and a program selection unit 128. The version selection unit 124 selects a version on the version selection screen 190 in FIG. 6, the request selection unit 126 selects an improvement request on the request selection screen 210 in FIG. 7, and the program selection unit 128 selects a program on the program selection screen 220 in FIG. Detect each selection. Details will be described later.

The notification unit 130 includes a release availability notification unit 132, a history display unit 134, and an improvement request display unit 144.
When it becomes possible to release a new version, the release enable / disable notification unit 132 notifies the administrator to that effect. Whether release is possible is determined according to the setting contents of the administrator on the version setting screen 180 of FIG. The history display unit 134 displays various screens described with reference to FIGS. The history display unit 134 includes an update history display unit 136, a request list display unit 138, a program list display unit 140, and a correction location display unit 142. The update history display unit 136 is a version selection screen 190 shown in FIG. 6, the request list display unit 138 is a request selection screen 210 shown in FIG. 7, and the program list display unit 140 is a program selection screen 220 shown in FIG. Displays the correction code screen 230 shown in FIG. The improvement request display unit 144 displays the improvement request list screen 170 shown in FIG.

Data processing unit 150:
The data processing unit 150 includes a registration unit 152, a correspondence state update unit 154, a correction location detection unit 156, a program update unit 151, a correction confirmation unit 153, and a release permission transmission unit 158.
When the improvement request and the modified version program are received, the registration unit 152 registers them in the request holding unit 162 and the correction program holding unit 164. Further, every time a new version of the business system 200 is released, the update history information in the update history holding unit 168 is updated. When the approval input is detected, the response status update unit 154 sets the corresponding improvement request completion flag to “corresponding”. The correction part detection unit 156 detects a difference between the corrected version program and the uncorrected program as a correction part, and registers the request ID and the correction part in the correction part holding unit 166 in association with each other. When the approval input is detected, the program update unit 151 records the approved modified version program in the release version holding unit 169. The modification confirmation unit 153 determines whether the contents of the modified version program on the development system 250 side and the modified version program on the maintenance support apparatus 100 side are related to R6. The release permission transmission unit 158 sends a release permission notification to the development system 250 on the condition that the approval is made by the administrator and the contents of the modified version program are the same on the development system 250 side and the maintenance support apparatus 100 side. Send to.
In the case of the business system 200 shown in the present embodiment, a plurality of developers may respond in parallel to a plurality of improvement requests. In this case, the modified version program that the administrator has determined to be appropriate as a response to a certain improvement request r1 may be subjected to further corrections for a response to another improvement request r2. For this reason, the release permission transmission unit 158 confirms that the contents of the modified version programs on the development system 250 side and the maintenance support device 100 side coincide with each other not only at the approval by the administrator but also at the release timing. Have confirmed. The release permission notification includes a request ID, a program ID, and the like. The development system 250 can release the modified version program held in its own modified program holding unit 254 on condition that the release permission notification is received.

Data holding unit 160:
The data holding unit 160 includes a request holding unit 162, a correction program holding unit 164, a correction location holding unit 166, an update history holding unit 168, and a release version holding unit 169. The request holding unit 162 holds the request ID and the content of the improvement request in association with each other. The correction program holding unit 164 holds the request ID and the corrected version program in association with each other. The corrected part holding unit 166 holds the request ID, the “program ID” of the corrected version program, and the corrected part in association with each other. The program ID herein may be data that can uniquely identify a program file, such as a program title name or an absolute path indicating the location of the program. The update history holding unit 168 holds update history information of each version of the business system 200. The release version holding unit 169 holds the same program as that constituting the business system 200.

FIG. 3 is a screen diagram of the improvement request list screen 170.
When the administrator terminal 204 is notified of the improvement request (R2), the administrator selects these improvement requests and transmits them to the maintenance support apparatus 100. The improvement request may be registered directly from the administrator terminal 204 to the maintenance support apparatus 100. The request receiving unit 114 of the maintenance support device 100 receives an improvement request from the administrator terminal 204 (R3). The registration unit 152 of the maintenance support device 100 assigns a request ID to the received improvement request and registers it in the request holding unit 162. The improvement request display unit 144 of the maintenance support apparatus 100 displays various improvement requests thus stored in the request holding unit 162 as an improvement request list screen 170 on an external terminal such as the administrator terminal 204 or the development terminal 206.

The request ID column 172 shows a request ID. The summary column 174 shows the content of the improvement request. When any improvement request is selected and the corresponding summary column 174 is clicked, text data indicating the specific content of the improvement request is displayed. In addition, various related information such as the name of the proposer, the proposal date, and the mail address of the proposer may be displayed. The urgency level column 176 indicates the urgency level of the improvement request. The urgency may be set by the proposer or the administrator. The response status column 178 indicates the status of the completion flag. The improvement request that has been handled is displayed as “completed”, and “not yet” is displayed when it is not supported. Information shown on the improvement request list screen 170 is mainly information held in the request holding unit 162.
By accessing the maintenance support device 100 via the development terminal 206, the worker can confirm what kind of improvement request is currently made and what kind of situation the response is.

FIG. 4 is a screen diagram of the version setting screen 180.
Usually, during the operation of the business system 200, new improvement requests are made one after another from employees. For example, when 10 improvement requests are proposed, the next version may be released after the response to these 10 improvement requests is completed, but the response to 10 improvement requests has been completed. Sometimes new requests for improvement may have been proposed. Therefore, the administrator sets in advance improvement requests to be handled by the next version among the improvement requests currently proposed. For example, in the case of the above example, it may be set that the next version is released when the response to seven of the ten improvement requests is completed.

  The administrator accesses the maintenance support apparatus 100 and displays the version setting screen 180 on the administrator terminal 204. Here, it is assumed that the current version of the business system 200 is “2.80”. The administrator sets a future release version in the version setting area 182. Here, “2.81” is set. The request ID designation area 184 is an area for designating a request ID of an improvement request (hereinafter referred to as “essential request”) to be dealt with for the release of version 2.81. In the figure, three improvement requests with request IDs = 04, 05, and 20 are set as essential requests. Therefore, if the improvement request with request ID = 04 (hereinafter referred to as “improvement request (04)”), improvement request (05), and improvement request (20) are resolved, the version is changed to version 2.81. Can be up. The response status area 186 indicates the response status of each essential request. The response status area 186 corresponds to the response status column 178 in FIG. According to the correspondence status area 186 in FIG. 5, the essential request (04) among the three essential requests has already been handled, but the remaining two mandatory requests are not yet supported.

  Here, it is assumed that the worker has uploaded a modified program corresponding to the essential request (05) from the development system 250 to the maintenance support apparatus 100. When the administrator confirms that the correction to the essential request (05) is valid via the user interface such as the correction code screen 230 of FIG. 9, the administrator inputs an approval. The response status update unit 154 of the maintenance support device 100 changes the setting of the completion flag for “request ID = 05” to “corresponding”. In association with the setting change of the completion flag, the response status column 178 of the improvement request list screen 170 and the response status area 186 of the version setting screen 180 are also updated.

The release permission / inhibition notifying unit 132 notifies the administrator that the version 2.81 is in a releaseable state when the completion flags of all the three essential requests with request IDs = 04, 05, and 20 are “corresponding”. . At this time, the registration unit 152 records request IDs = 04, 05, and 20 in the update history storage unit 168 in association with version 2.81 as improvement requests that have been handled in version 2.81. The registration unit 152 also records, in the update history holding unit 168, the request ID of the improvement request that has been carried over without being supported when the version 2.81 is released. That is, in the update history information, the version, the request ID of the improvement request that has been handled in the version, and the request ID of the improvement request that remains unsupported when the version is released are associated.
Version 2.81 is released after the final check of the correction content by the correction check unit 153 as described above.

FIG. 5 is a schematic diagram for explaining a method of specifying a correction portion of the source code in response to the improvement request.
Here, the association between the request ID and the corrected part will be described. As an example, it is assumed that three programs “program4”, “program10”, and “program12” have been modified to meet the improvement request (20). The three modified programs are transmitted from the development system 250 to the maintenance support apparatus 100 after specifying the request ID = 20. The registration unit 152 of the maintenance support apparatus 100 registers the request ID = 20 and the three modified version programs in the modified program holding unit 164 in association with each other.

  The correction location detection unit 156 acquires the same programs “program4”, “program10”, and “program12” as the current release version 2.80 from the release version holding unit 169. The correction location detection unit 156 detects the difference between the corrected program “program4” and the unmodified program “program4” of version 2.80 as the correction location 188a. The difference may be detected by an existing algorithm, for example, an algorithm equivalent to the “diff” command of UNIX (registered trademark). Similarly, the correction location detector 156 detects the correction location 188b for “program10” and the correction locations 188d and 188e for “program12”.

The registration unit 152 records the program ID of “program4” and the correction part 188 a in association with the request ID = 20 in the correction part holding part 166. The correction part here is, for example, a value indicating the range of the correction part in the program file by a row number or a column number. Similarly, the registration unit 152 associates “program10” with the corrected portion 188b, “program12”, and the corrected portions 188c and 188d with the request ID = 20, and records them in the corrected portion holding unit 166.
In this way, the corrected part holding unit 166 holds the request ID, the program ID, and the corrected part in association with each other.

  When the administrator refers to the improvement request list screen 170 in FIG. 3, the version setting screen 180 in FIG. 4, the correction code screen 230 in FIG. 9, and the like and confirms the validity of the correction code associated with the improvement request (20). Enter approval. If necessary, you can test the modified version of the program.

FIG. 6 is a screen diagram of the version selection screen 190.
When all required requirements are completed, the next version can be released. Each process of uploading an improvement request, uploading a modified version program corresponding to the improvement request to the maintenance support apparatus 100, checking the correction contents by the administrator, final check before release by the correction checking unit 153, and releasing the new version are as follows: Executed in parallel. For this reason, when a certain version is released, there is an improvement request solved by the version, and there is also an improvement request which is carried over unresolved at the time of release. The version selection screen 190 shows the ratio between the improvement request solved by the version and the improvement request that remains unsolved when the version is released for each version.

  The update history display unit 136 of the maintenance support device 100 displays the version selection screen 190 on the external terminal. The update history display unit 136 refers to the update history holding unit 168 and, for each version, the request ID of the improvement request that has been handled in the version, and the improvement request that remains unsupported when the version is released. The request ID is detected, and the version selection screen 190 is formed.

  In the figure, the release date of version 2.74 is “October 15, 2007”, and the number of improvement requests solved by version 2.74 is 96. In addition, when version 2.74 was released, 11 improvement requests remained unsolved. The next version 2.75 was released on October 28, 2007. The number of improvement requests solved by version 2.75 is 149. That is, it can be seen that many improvement requests have been proposed even after version 2.74 has been released, and many of them have been resolved in version 2.75.

  According to the version selection screen 190, the user can confirm on a single screen how much the improvement request has been solved in each version of the business system 200 and how much the release has been released. Here, information about already released versions from version 2.74 to 2.76 is shown, but information about future versions that have not yet been released is also displayed in a similar format. For example, for version 2.81 that has not yet been released, the ratios of the number of resolved essential requests, the number of unresolved essential requests, the number of resolved improvement requests, the number of unresolved improvement requests, etc. may be displayed in a graph. .

  When the user clicks on any version, the version selection unit 124 of the maintenance support apparatus 100 detects that the version has been selected. Here, it is assumed that version 2.76 is selected.

FIG. 7 is a screen diagram of the request selection screen 210.
When version 2.76 is selected on the version selection screen 190, the request list display unit 138 displays a request selection screen 210 showing a list of improvement requests solved in version 2.76. The request ID column 191 shows a request ID. An outline column 192 shows an outline of the improvement request. The urgency column 194 shows the urgency of the improvement request. The request ID column 191, the summary column 192, and the urgency level 194 correspond to the request ID column 172, the summary column 174, and the urgency column 176 in the improvement request list screen 170 of FIG. The completion date column 196 indicates the date on which the administrator has approved the response to the improvement request.
According to the request selection screen 210, the user can confirm on one screen what kind of improvement request has been resolved in each version of the business system 200.

  When the user clicks on any improvement request, the request selection unit 126 of the maintenance support device 100 detects that the improvement request is selected. Here, it is assumed that the improvement request (26) is selected.

FIG. 8 is a screen diagram of the program selection screen 220.
When the improvement request (26) is selected on the request selection screen 210, the program list display unit 140 displays a program selection screen 220 showing a list of programs modified in association with the improvement request (26). In the request detail area 240, detailed information regarding the improvement request (26) is displayed. In the request detail area 240, for example, the request ID for improvement request = 26, the proposer of the improvement request, the manager who confirmed the proposal date, the urgency level, the response to the improvement request, the confirmation date, and the improvement request A text or the like indicating specific contents is shown.

The correction list column 242 indicates a program ID of a program corrected in relation to the improvement request (26). In the case of the figure, the program ID is an absolute path indicating the location of each program. According to the correction list column 242 of FIG. 9, it can be seen that two programs “program18” and “program24” have been corrected in order to respond to the improvement request (26). Based on the information held in the correction program holding unit 164, the program ID of the program corrected in relation to the improvement request (26) can be specified.
According to the program selection screen 220, the user can confirm on a single screen which program has been subject to correction for each improvement request of each version.

  When the user clicks on one of the program IDs from the correction list column 242, the program selection unit 128 of the maintenance support apparatus 100 detects that the program has been selected. Here, it is assumed that “program18” is selected.

FIG. 9 is a screen diagram of the correction code screen 230.
When “program18” is selected on the program selection screen 220, the correction part display unit 142 displays a correction code screen 230 indicating the source code of “program18” that was corrected when the version 2.76 was released out of “program18”. Let The correction part display unit 142 specifies the correction part 188 of “program18” associated with the request ID = 20 in the correction part holding unit 166. This correction portion 188 is nothing but the difference between “program18” in version 2.75 and “program18” in version 2.76. The correction part display unit 142 displays the correction part 188 in a different display mode so as to be distinguishable from other parts. For example, the character size, character color, background color, font, and the like may be changed only in the corrected portion 188, or character decorations such as an underline may be added only in the corrected portion 188. As described above, it is desirable to highlight the correction portion 188 so that the user can identify the correction portion 188 at a glance.
According to the correction code screen 230, the user can confirm which part of each corrected version program corresponding to each improvement request of each version has been corrected.

  In FIGS. 6 to 9, the description has been given of the aspect of confirming the correction part etc. for the released version, but the same applies to the case of the unreleased version. For example, when an unreleased version 2.81 is selected on the version selection screen 190, a list of essential requests of version 2.81 and improvement requests resolved after version 2.81 are displayed on the request selection screen 210. For example, when the essential request (20) is selected here, a list of programs corrected for the essential request (20) is displayed on the program selection screen 220. When one of the programs is selected, the correction part is highlighted on the correction code screen 230. When the administrator confirms that the highlighted portion corresponds to the content of the essential request, the administrator performs a correspondence confirmation input.

  Further, the release contents may be controlled not in version units but in improvement request units. For example, it is assumed that the trailing stop function is installed according to the mandatory request A of version 2.78 and the relay order function is installed according to the essential request B. Here, it is assumed that the business system 200 delivered to the securities company P needs both a trailing stop function and a relay order function. On the other hand, it is assumed that the business system 200 delivered to the securities company Q needs only the trailing stop function. In this case, the securities company A may release a program of version 2.78 or later. On the other hand, after releasing version 2.77 to securities company B, it is only necessary to reflect the correction contents corresponding to the essential request A. For this reason, the function which should be mounted according to a customer can be selected comparatively easily.

FIG. 10 is a sequence diagram showing a processing process until the next version is released.
The improvement request display unit 144 of the maintenance support apparatus 100 transmits an improvement request to the development system 250 by transmitting a web page that forms the improvement request list screen 170 (S10). On the development system 250 side, the operator makes necessary corrections to the program (S12). The modified version program is registered in the modified program holding unit 254 (S14) and transmitted to the maintenance support device 100 (S16). The maintenance support apparatus 100 once holds the corrected version program in the correction program holding unit 164.

  The administrator confirms the corrected part and inputs the approval (S18). After the approval, the program update unit 151 registers the corrected version program of the correction program holding unit 164 in the release version holding unit 169 (S20). When the necessary correction is completed for the improvement request transmitted in S10, the completion flag for this improvement request is set to “corresponding” (S21).

  When the completion flag is set to “completed” for all the essential requests for the next version, the release permission / inhibition notifying unit 132 notifies the administrator that the next version can be released (S22). At this time, the release permission transmission unit 158 first notifies the development system 250 side to prepare for the release of the next version (S24). The development system 250 transmits the modified program modified after the release of the current version to the maintenance support device 100 (S26). The correction confirmation unit 153 confirms that there is no difference between the modified version program held in the release version holding unit 169 and the modified version program received in S26 (S28). If there is no difference, the release permission transmission unit 158 transmits a release permission notification to the development system 250 (S30). At this time, the registration unit 152 updates the update history information (S32). On the other hand, on the development system 250 side, the modified version program of the modified program holding unit 254 is registered in the release version holding unit 252 (S34) and released as the next version (S36).

The maintenance support apparatus 100 has been described based on the embodiments.
According to the maintenance support device 100, when an improvement request is proposed during the operation of the business system 200, the improvement request list screen 170 promptly discloses the contents of the improvement request. When the worker corrects several program files in response to the improvement request, not only the improvement request and the program file to be corrected but also the correction portion can be automatically associated.

Normally, when a modified version of a program is uploaded, it is necessary to detect the difference before and after the modification and confirm the modification contents. However, when the modification for responding to one improvement request extends to a plurality of program files, the load of such confirmation work increases. Also, depending on the programmer, there may be a case where a part not related to the improvement request is also corrected. For this reason, at the time of correction, there is always a possibility that an unknown code unrelated to the improvement request will be mixed in. On the other hand, since the maintenance support apparatus 100 shown in the present embodiment holds the improvement request and the correction portion in association with each other, it is substantially unnecessary for the administrator to detect the difference before and after the correction. As a result, the administrator's burden of confirmation can be reduced, so that it is easy to eliminate the possibility that unknown codes are mixed in.
Further, after confirming that there is no difference between the modified version program on the development system 250 side and the approved modified version program on the maintenance support apparatus 100 side, release by the development system 250 is permitted. This eliminates the possibility of unapproved revisions being merged into the official version prior to release.

  Further, since the version and the essential request can be set in association with each other on the version setting screen 180, information on which improvement request is dealt with when the next version is released can be shared among a plurality of users. Furthermore, the version selection screen 190, the request selection screen 210, the program selection screen 220, and the correction code screen 230 are used to correct the version update history, the improvement requests resolved in each version, and the response to each improvement request. It is possible to trace the program file, and further, to the correction part. For this reason, even when the business system 200 including a large number of program files is operated for a long period of time, the update history of the source file can be efficiently managed.

  The present invention has been described based on the embodiments. The embodiments are exemplifications, and it will be understood by those skilled in the art that various modifications can be made to combinations of the respective constituent elements and processing processes, and such modifications are within the scope of the present invention. .

It is a hardware block diagram which shows the relationship between a business system, a maintenance assistance apparatus, and a development system. It is a functional block diagram of a maintenance support device. It is a screen figure of an improvement request list screen. It is a screen figure of a version setting screen. It is a schematic diagram for demonstrating the method to specify the correction location of the source code with respect to an improvement request. It is a screen figure of a version selection screen. It is a screen figure of a request selection screen. It is a screen figure of a program selection screen. It is a screen figure of a correction code screen. It is a sequence diagram showing a processing process until the next version is released.

Explanation of symbols

  100 maintenance support device, 110 user interface processing unit, 112 input unit, 114 request reception unit, 116 correction reception unit, 118 approval detection unit, 120 version setting unit, 122 selection unit, 124 version selection unit, 126 request selection unit, 128 Program selection section, 130 notification section, 132 release availability notification section, 134 history display section, 136 update history display section, 138 request list display section, 140 program list display section, 142 correction location display section, 144 improvement request display section, 150 Data processing unit, 152 registration unit, 154 correspondence status update unit, 156 correction location detection unit, 158 release permission transmission unit, 160 data holding unit, 162 request holding unit, 164 correction program holding unit, 166 correction location holding unit, 168 Update history holding unit, 170 Improvement request list screen, 172 Request ID column, 174 Summary column, 176 Urgency column, 178 Corresponding status column, 180 Version setting screen, 182 Version setting region, 184 Request ID designation region, 186 Corresponding status Area, 188 Correction location, 190 Version selection screen, 191 Request ID column, 192 Summary column, 194 Urgency column, 196 Completion date column, 200 Business system, 202 Employee terminal, 204 Administrator terminal, 206 Development terminal, 210 Request selection screen, 220 Program selection screen, 230 Modification code screen, 240 Request details area, 242 Modification list column.

Claims (9)

It is connected via a communication line to a development system that is responsible for correcting and releasing multiple programs that make up the business system.
A request receiving unit for receiving an improvement request for the business system in operation from an external terminal;
For each of one or more improvement requests, a request holding unit that holds improvement request information that associates a request ID that uniquely identifies the improvement request with text data that indicates the content of the improvement request;
A request transmitter for transmitting an improvement request to the development system;
The program to be corrected by the transmitted improvement request as a target program, the target program that has been corrected, and the correction receiving unit that receives from the development system the request ID of the improvement request that triggered the correction;
A program holding unit for holding the same program as the program constituting the business system;
A correction location detector that detects the difference between the received target program after correction and the target program before correction as a correction location;
A correction location holding unit that holds the correction location in association with the request ID of the improvement request that triggered the correction;
An approval detection unit that detects an approval input indicating that the correction content of the received target program is approved from an administrator who refers to the correction portion with respect to the improvement request;
On condition that the approval input is detected, a program update unit that records the modified target program in the program holding unit as an approved target program;
By re-receiving the target program from the development system when releasing the target program after correction by the development system, and detecting again the difference between the received target program and the approved target program held A correction confirmation unit for confirming whether or not an unapproved correction is newly applied to the target program on the development system side;
A release permission transmitting unit for notifying the development system of a release permission of the target program, on the condition that an unapproved modification has not been made to the target program held on the development system side;
A maintenance support apparatus comprising: The business system is a system in which an update history is managed by version,
A version setting unit for detecting selection of an improvement request to be supported for a future version release among the improvement requests registered in the improvement request information;
Among the improvement requests registered in the improvement request information, a response state update unit that sets a predetermined completion flag to already processed for an improvement request that has already been processed by correcting the program;
A release enable / disable notification unit for notifying the administrator that the future version can be released when a completion flag is set to already supported for all improvement requests to be supported in the future version;
The maintenance support apparatus according to claim 1, further comprising: For each of the one or more versions, an update history holding unit that holds update history information that associates one version with the request ID of the improvement request that has been handled by the version;
An update history display unit for displaying the update history information on a screen;
The maintenance support apparatus according to claim 2, further comprising: A version selection unit that detects selection of one of the one or more versions indicated in the update history information;
A request list display unit that refers to the improvement request information and the update history information, and displays a list of text data indicating the content of the improvement request that has been handled by the selected version;
The maintenance support apparatus according to claim 3, further comprising: An improvement request selection unit for detecting selection of any improvement request among one or more improvement requests displayed in a list corresponding to the selected version;
A program list display unit for displaying a list of program IDs of programs modified in response to the selected improvement request;
The maintenance support device according to claim 4, further comprising: A program selection unit for detecting selection of any one of the one or more program IDs displayed in a list corresponding to the selected improvement request;
About the program specified by the selected program ID, a correction location display unit that displays the correction location corresponding to the selected improvement request on the screen in a manner that can be distinguished from other locations;
The maintenance support apparatus according to claim 5, further comprising: A request receiving unit for receiving a request for improvement of an operating business system;
A request holding unit that holds improvement request information that associates a request ID that uniquely identifies an improvement request with text data indicating the content of the improvement request for each of the one or more improvement requests;
In response to any improvement request registered in the improvement request information, a program and a request ID that have been corrected for one or more programs out of a plurality of programs constituting the business system are received from an external device. A modified receiver to receive,
About the program to be corrected among the plurality of programs, a correction location detector that detects a difference between the program after the correction and the program before the correction as a correction location;
A correction location holding unit that holds the correction location in association with the request ID of the improvement request that triggered the correction;
A maintenance support apparatus comprising: The ability to receive requests for improvement on operational business systems;
For each of one or more improvement requests, a function for holding improvement request information in which a request ID for uniquely identifying an improvement request is associated with text data indicating the content of the improvement request;
A function of transmitting an improvement request to a development system in charge of correcting and releasing a plurality of programs constituting the business system;
A function for receiving from the development system a target program that has been corrected in response to the transmitted improvement request, and a target program that has been corrected, and a request ID of the improvement request that triggered the correction When,
A function for holding the same program as that constituting the business system;
A function for detecting the difference between the received target program after correction and the target program before correction as a correction part;
A function of holding the correction location in association with the request ID of the improvement request that triggered the correction;
A function for detecting an approval input indicating that the amendment of the received target program is approved from the administrator who refers to the amended part with respect to the improvement request;
A function of holding the modified target program as an approved target program on the condition that the approval input is detected;
By re-receiving the target program from the development system when releasing the target program after correction by the development system, and detecting again the difference between the received target program and the approved target program held , A function for confirming whether or not an unapproved correction is newly applied to the target program on the development system side;
A function for notifying the development system of the release permission of the target program, on the condition that an unapproved modification has not been made to the target program held on the development system side;
A maintenance support program characterized by causing a computer to demonstrate A function to receive an improvement request for an operating business system;
For each of one or more improvement requests, a function of holding improvement request information that associates a request ID for uniquely identifying an improvement request with text data indicating the content of the improvement request;
In response to any improvement request registered in the improvement request information, a program and a request ID that have been corrected for one or more programs out of a plurality of programs constituting the business system are received from an external device. The function to receive,
A function of detecting a difference between a program after the correction and a program before the correction as a correction portion for the program to be corrected among the plurality of programs,
A function of holding the correction portion in association with the request ID of the improvement request that triggered the correction;
A maintenance support program characterized by causing a computer to demonstrate

Images