JP2008176803A - Level-down detection program, level-down detection method, and management program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To mechanically prevent a fault in releasing products when updating the products in parallel. <P>SOLUTION: A program for allowing a computer to detect a failure in updating program products including a plurality of modules comprises steps of: providing update identification information for identifying the updating work of the program products; recording information for identifying the updated modules, and information indicating the updated time of the modules for every updating work together with the update identification information; comparing the updated time of modules to be released with that of modules not to be released; and instructing the execution of predetermined processing when the updated time of the modules to be released is later than that of the modules not to be released. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a program product update management technique.

  In industrial fields where competition between companies is severe, the release cycle of new products and successor products is extremely short. For example, in an information device such as a personal computer, a server, a PDA, or a mobile phone, a new product is shipped in a cycle of several months. Furthermore, in these information devices, in addition to the shipment of new products, the shipment of revised products that take measures against defects in the current product is also complicated. For this reason, there are many cases where development of products for a plurality of generations is performed in parallel in a short period of time.

  In addition, one generation of such a product usually includes a plurality of correction work and update work. In many cases, such a plurality of correction operations and update operations are performed in parallel.

  Such an information device operates by a combination of hardware and a program product as is well known. Among them, the program product is composed of a combination of many modules.

  Furthermore, program products included in information equipment are generally large-scale and have been developed or updated by many developers. Therefore, when a new product, a successor product, or a revised product is developed over a plurality of generations in a short period of time, the correction module needs to be accurately managed over each generation.

  In particular, in the development of a program product, the program product is released through an individual test for each developer, followed by a combination test and a system test. In many cases, a program product is developed in an integrated compilation environment in which related source programs are held together and compiled.

  In such an integrated compilation environment, when multiple corrections and development of products for multiple generations are performed in parallel, changes or corrections in a specific source program or specific module in one generation are developed in other generations. The content may be adversely affected. Conventionally, such work has been performed to manually check the consistency between generations of such program products and the consistency between correction operations. Such manual confirmation work takes a lot of time and sometimes causes human error.

  The present invention has been made in view of such problems of the conventional technology. That is, an object of the present invention is to mechanically prevent defects at the time of product release in a situation where a plurality of update operations for a product are performed in parallel.

In order to solve the above problems, the present invention employs the following means. That is, the present invention is a program for causing a computer to detect a defect at the time of updating a program product including a plurality of modules. The step of providing update identification information for identifying an update operation of the program product; The step of recording the information for identifying the updated module and the information indicating the update time of the module together with the update identification information, the update target module for the release schedule and the target module for the update schedule that is not scheduled to be released A comparison step for comparing the update time with respect to the module, and a step for instructing execution of a predetermined process when the update time of the module to be released is newer than the update time of the module not to be released corresponding to the module It is.

  Here, the information for identifying the update work identifies updates, corrections, and the like performed for a predetermined part of the program product in a predetermined period. This information is called, for example, a correction number, and one or more such update operations are combined to constitute a generation of program products. The generation of a program product is also called a version, version, or revision.

  The computer executing this program compares the update dates of the corresponding modules in the update work scheduled to be released and the update work not scheduled to be released. This update date may include time.

  Then, when the update time of the module scheduled to be released is newer than the update time of the module not scheduled to be released corresponding to the module, this computer instructs execution of a predetermined process because there is a possibility of failure.

  In this way, a computer that executes this program mechanically detects a defect associated with an update of a program product even when a plurality of update operations for one program product are performed in parallel.

  Preferably, the method further comprises a step of accessing such a file storing a module identified and updated for each update operation and referring to an update time of the file, and in the comparison step, the module to be released or For at least one of the modules not scheduled to be released, the update time of the module may be compared based on the update time referenced from the file.

  That is, the computer accesses the file storing the module instead of comparing the update time with the information for identifying the module and the information indicating the update time of the module recorded on the update module, and updates the file. Get For this reason, the said computer can grasp | ascertain the update time of a module reliably.

  Preferably, the predetermined process is a postponement of release of the program product to be released. Preferably, the predetermined process may be a process for promoting the release of a program product that is a program product that is not a release target and includes a module older than the module to be released. Here, the release promotion process is, for example, a test of a program product that is not a release target.

  Further, the present invention is a program for causing a computer to detect a defect at the time of updating a program product including a plurality of modules, and providing generation identification information for identifying the update generation for each update generation of the program product; For each of the update generations, the step of recording the information for identifying the updated module and the information indicating the update time of the module together with the generation identification information, and updating in the update generation to be released and the update generation not to be released A comparison step for comparing the update time of the module being released, and a step for instructing execution of a predetermined process when the update time of the module scheduled to be released is newer than the update time of the unscheduled module corresponding to the module; May be provided.

Here, the update generation means a generation on the history of the program product including the result of one or more update operations of the program product. A generation is also called a version, version, or revision. However, this update generation may correspond to one update operation.

  The computer that executes this program compares the update date of the corresponding module between the update generation targeted for release and the update generation not targeted for release. This update date may include time.

  Then, when the update time of the module scheduled to be released is newer than the update time of the non-release scheduled module corresponding to the module, the computer instructs execution of a predetermined process because there is a possibility of failure.

  In this way, the computer mechanically detects a defect associated with the update of the program product even when the program product is updated in parallel for a plurality of generations.

  The present invention may be a method in which a computer, other devices, machines, etc. execute any one of the processes described above. Further, the present invention may be a program in which a computer or other device, machine, or the like realizes any one of the functions described above is recorded on a computer-readable recording medium.

  As described above, according to the present invention, it is possible to mechanically prevent defects in product release in a situation where a plurality of update operations for a product are performed in parallel.

  Hereinafter, an information system according to an embodiment of the present invention will be described with reference to FIGS.

  FIG. 1 is a diagram showing an example of occurrence of a problem when a program product is released, FIG. 2 is a diagram showing the principle of the information system, FIG. 3 is a system configuration diagram of the information system, and FIG. FIG. 5 is a data flow diagram of the information system, FIG. 5 is a diagram showing an operation flow at the time of program product correction, FIG. 6 is a diagram showing an operation flow at the time of release, and FIG. FIG. 8 is a flowchart showing details of the level down prevention check process (S2 in FIG. 7).

<Functional overview>
FIG. 1 shows an example of a problem occurring when a program product is released. FIG. 1 shows the history of a failure occurrence example in a situation where two generations of one program product are released in a short period of time.

  Here, the program product is, for example, a system program or an application program used on a personal computer. In the present embodiment, the program product is also referred to as an asset.

Such a program product is generally composed of a plurality of modules. In FIG. 1, a file (dynamic link library) called A.dll is shown as an example of such a module. Here, it is assumed that a file (so-called load module) obtained by compiling source programs A.cpp and B.cpp is included in A.dll.

The generation is also called a version, revision, etc., and identifies the program product to be released. In FIG. 2, the correction targets for each generation are clearly shown as incident X and incident Y. Hereinafter, the background of the occurrence of the failure will be described with reference to FIG.

(1) On December 7 (“2001” shown in FIG. 1 is omitted. The same applies hereinafter), incident X (a source program called A.cpp) was corrected and the compilation was completed. In this case, the entire dynamic link library A.dll including the compilation result of A.cpp (this is called a load module) is compiled. The dynamic link library created at this time is called A.dll50. The A.dll 50 is placed in a test waiting state (arrow 101).

(2) On December 10, Incident Y (source program called B.cpp) was corrected and compilation was completed. The compilation result of B.cpp is included in the same dynamic link library A.dll as above.

Therefore, the entire dynamic link library A.dll is compiled again. Since this compilation is executed in the integrated compilation environment, A.cpp corrected in incident X is also compiled. The dynamic link library generated by this compilation is called A.dll 51. This A.dll 51 is also placed in a test waiting state (arrow 102).

(3) On December 10, the test of A.dll 51 corresponding to incident Y (B.cpp) is completed (arrow 103), and A.dll 51 is released as an incident Y corresponding module (arrow 104). However, at this point, the test for incident X is incomplete.

(4) On December 12, the test of A.dll 50 corresponding to incident X (A.cpp) is completed (arrow 105), and A.dll 50 is released as an incident X response module (arrow 106).

  This situation includes the following problems (this problem is also called level down).

First, as described in the above (3), the A.dll 51 corresponding to the incident Y is released as it is even though the A.cpp compilation result of the unfinished test is included.

Secondly, the A.dll 50 released later in the above (4) does not include the correction result of B.cpp corresponding to the incident Y. For this reason, if A.dll 51 released later is overwritten by A.dll 50 released later, the correction result of incident Y will disappear on the user side receiving the release.

  FIG. 2 is a diagram showing the principle of the information system for avoiding such a problem. FIG. 2 shows a level-down check screen 19 in which a user (a manager in charge of release) checks for the presence or absence of such a defect in the program product, and an overview of processing executed by an instruction from the level-down check screen 19. ing.

  The level down check screen 19 is a setting release VL (version level) column 31, a comment column 32, a planned VL column 33, a level down check display column 34, a display button, a check button 20, and a setting target at the bottom of the screen. An asset column 35 is included.

  The administrator sets a version level indicating the version of the release target program in the setting release VL31. The version level is, for example, a character string such as V10L10.

  Further, the administrator sets a comment related to the version level in the comment field 32. The comment is, for example, “Failure No. 0011 compatible module” or the like.

  In addition, the administrator sets the version level that is scheduled to be released in the planned VL column 33, and presses the display button, so that the revision No. belonging to that version level is set. Can be displayed. Such a modification No. Is displayed in the setting target asset column 35.

  Here, the correction No. Is information for specifying a group of correction work and update work for the program product. In addition, the correction No. Identifies the results of such corrections and updates. Then, one or more results of such correction work and update work are combined to constitute one version level.

  The level down check display field 34 displays whether or not a level down check is executed.

  In the setting target asset column 35, the revision No. to be released is shown. A list of will be displayed. Each row of the table of the setting target asset column 35 has fields for a release target check mark, a correction number, and a case number. Here, the check mark indicates the correction number. Specifies that the correction result of the correction work is to be released.

  When the administrator sets a release target check mark for a desired revision number line and presses the check button 20, the level down check is started.

  For example, in the example of FIG. 2, the release module management table of the program product indicated by the release target revision number (001 to 003) is read and compared with the module management table of the revision number that is not the release target.

  Modules updated by compiling the source program are recorded in the release module management table. As shown in FIG. And a list of modules that have been modified by the correction work. The module list includes the name of the modified module and the update date (compile date) when the module is updated.

Here, for example, the correction No. The update date of the module A.dll recorded in the release module management table 20A of 0001 is December 10, 2001. On the other hand, correction No.
. The update date of the module A.dll recorded in the release module management table 20B of 0031 is December 7, 2001.

  Therefore, the correction No. Among the modules to be released this time identified by 0001, there is a module whose modification date is newer than a module that is not a release target (released later).

  In such a situation, as described in FIG. At the time of 001 release, A.dll may contain untested modifications. Later, the correction No. With the release of 0031, the released content may be deleted.

On the other hand, for example, the modification No. The update date of module B.dll of 0001 is December 11, and the modification No. The update date of module B.dll of 0031 is older than December 18th. Therefore, it can be seen that the module B.dll does not contain any defects.

In addition, the correction No. Modules Y.EXE and Z.dll are recorded in the release module management table 20A of 0001. However, these modules have the modification No. It is not recorded in the release module management table 20B of 0031. This is because Y.EXE and Z.dll are modified No. Although it was updated in 0001, the correction No. 0031 indicates that it has not been updated.

  In addition, the correction No. Modules such as XX01.EXE and XX02.EXE are recorded in the release module management table 20B of 0031. However, these modules have the modification No. It is not recorded in the release module management table 20A of 0001.

  In this way, a module that is recorded in one of the two release module management tables and not recorded in the other release module management table does not cause a problem. This is because the modules not recorded in the release module management table are not compiled.

<System configuration>
FIG. 3 is a system configuration diagram of the information system. This information system includes a web server 1, an asset management server 2, a development server 3 (including a compilation server), a release server 4 (including a test server), a failure / Q / A registration server 5 and an SQL server 6. Yes.

  The asset management server 2 executes an asset management program and manages versions of program products, modules constituting each program product, source programs for compiling the program products and modules, and the like. Here, asset management refers to so-called program product version management.

  The development server 3 including the compile server is used for editing and compiling the source program. The release server 4 including the test server provides a test environment for the program product.

  The failure / Q / A registration server 5 registers notification of failure information from the service department, Q / A (question and answer), and the like. The SQL server 6 holds information related to the development environment and information registered from the failure / Q / A registration server 5.

  The web server 1 provides a web page to the terminal 10 used by an administrator or developer, information on version management, loading / unloading of source programs, failure information, Q / A (questions and answers about program products), etc. I will provide a.

  Further, the web server 1 executes an asset management control unit (program) to detect a defect at the time of program product release, that is, a level down.

<System operation flow>
FIG. 4 is a data flow diagram of the information system. In this information system, the source program of the program product is distinguished for each generation and stored in the database as the original 21.

The user accesses the information system through his / her terminal 10 and acquires a necessary source program from the original 21. That is, the user accesses a predetermined web page, specifies a source program necessary for updating, and requests the asset management server 2 to lend the source program. Then, the asset management server 2 is output to the management issue folder 22 and further moved to the rental folder 23 of the development server 3 ((1) in FIG. 4 (here, the whole 1 is represented as (1). And so on)). The user copies the source program from the rental folder 23 of the development server 3 to his / her terminal 10 and performs a program correction operation. However, the user may modify the program as it is in the lending folder 23.

  After the correction is completed, the user returns the corrected source program to the return folder 24. Then, the user accesses a predetermined web page and returns the source program. By this return operation, the source program of the return folder 24 is transferred to the management reception folder 25. Further, the source program in the return folder 24 is transferred to the integrated compilation environment folder 26 ((2) in FIG. 4).

  The compile server compiles the copied source program and all source programs incorporated in the same module as the source program, and creates an updated module.

  Further, the compile server returns the updated module to the management reception folder 25 ((3) in FIG. 4). At this time, the asset management server 2 receives the modification No. Is issued, and the revision number is displayed in the revision module management table. Record the module name and update date of the returned module. Also, the compile server changes the updated module to a directory configuration that matches the integrated test environment ((4) in FIG. 4).

  Then, the compile server stores the module in the test expansion waiting directory 29 ((5) in FIG. 4). The test server 4 that provides the integrated test environment sequentially reads the modules stored in the test deployment waiting directory 29 and deploys them to the test environment.

  In the test server 4, the updated module test is executed in the integrated test environment. When the test is successfully completed, the user can confirm the correction No. that the test is completed. Is input to a predetermined web page. With this input, the asset management server 2 registers the module updated from the management reception folder 25 in the original 21 ((6) in FIG. 4).

  The administrator confirms the modification No. that has been tested. Of these, the revision number to be released is Collect and set the version level to release. And the correction No. included in the version level. Perform a level-down check on the correction results of.

  When the level down check ends normally, the administrator transfers the modules included in the version level to the release environment folder 28 of the remote maintenance server via the work folder ((7) in FIG. 4).

  The remote maintenance server transfers the module of the release environment folder 28 to the end user's computer at a predetermined time according to the contract conditions with the end user.

  FIG. 5 shows an operation flow when the program product is corrected. First, the user (described as “developer” in FIG. 5) takes out the source program to be corrected from the original 21 to his / her terminal 10 by operating a predetermined web page ((1) in FIG. 5). After completing the correction work, the user returns the corrected source program to the return temporary directory 24A by an operation on the web page ((3) in FIG. 5). Here, the temporary return directory 24A corresponds to the return folder 24 and the management reception folder 25 shown in FIG.

The returned source is transferred to the compilation environment folder 26 ((4) in FIG. 5). In this compilation environment folder 26, the source program is compiled. A technique for executing only compilation related to such a modified source program is widely known as a make command in the UNIX system, for example.

  Next, the difference between the compilation results is extracted ((6) in FIG. 5). The difference is a set of modules updated by compiling the source program transferred to the compilation environment. This difference is copied to both the return temporary directory 24A and the test environment folder 27.

  The test server 4 expands the copied difference (a set of updated modules) in the test environment ((7) in FIG. 5). Deployment here means installing the updated module in a test environment. The user executes the test in the test environment ((8) in FIG. 5).

  After the test is completed, the user sets the test completion on a predetermined web page. With this setting, the test completion e-mail is notified to the administrator ((10) in FIG. 5). The administrator executes correction end approval processing through a predetermined web page ((11) in FIG. 5). As a result of this approval process, the file (the corrected source program and the updated module) in the temporary return folder is reflected in the original 21. At this time, the corresponding correction No. In the release module management table, the update module name and the update date are recorded ((12) in FIG. 5).

  FIG. 6 shows an operation flow at the time of release. In this process, the administrator selects a revision number to be released on the level down check screen 19 ((1) in FIG. 6).

  Then, the administrator presses the check button 18 (see FIG. 2) on the level down check screen 19 and designates execution of the level down check. Thus, a level down check, that is, a defect check at the time of program product release is executed ((2) in FIG. 6).

  Then, the asset management server 2 sets the revision number to be released. And the revision number that is not the release target. The release module management tables (tables 20A and 20B in FIG. 6) are compared. In this comparison, if the update date of the release target module is newer than the update date of the non-release target module (if the update date of the non-release target module is older than the update date of the release target module), the bug, A level down is detected.

  Next, the asset management server 2 sets the revision number to be released. The update date of the module recorded in the release module management table identified by (1) is compared with the update date of the file stored in the test environment folder 27 and storing the module. In this comparison, when the update date of the release target module is newer than the update date of the file storing the module of the same name in the test environment folder 27 (when the update date of the file in the test environment folder 27 is older), That is, a level down is detected.

  Next, when no defect is detected, the asset management server 2 determines the revision No. to be released. Is displayed on a predetermined web page. The administrator can change the revision number of the release target. To determine the release target ((3) in FIG. 6).

  The asset management server 2 confirms the confirmed revision number. The module to be released is extracted from the original 21 based on the release module management table identified by (4 in FIG. 6).

<Action>
FIG. 7 shows a correction module release process in this information system. This process is realized by the asset management server 2 shown in FIG. 3 executing the information processing program.

  In this process, the asset management server 2 first receives a release target selection by the administrator (S1). Next, the asset management server 2 executes a level down prevention check process (S2).

  Next, the asset management server 2 determines whether or not the level can be lowered (S3). If there is no possibility of level down (NO in S3), the asset management server 2 extracts the release target module and ends the process (S4).

  On the other hand, if there is a possibility of level down (YES in S3), the asset management server 2 receives a level down prevention treatment selection from the administrator (S5). If the level down prevention measure is “Releasing Release”, the asset management server 2 prompts the test of the modification number corresponding to the module that is not subject to release but has an old update date.

  Thereby, for example, a predetermined message is notified to the developer terminal 10. The developer completes the test of the modification number and notifies the completion report. Upon receiving this notification, the asset management server 2 sets the program product with the modification number as a release target and returns control to S1.

  Further, when the level down prevention measure is “release postponement”, the asset management server 2 sets the revision number set as the release target as the non-release target (S7). Then, the asset management server 2 returns the control to S1.

  FIG. 8 shows details of the level down prevention check process (S2 in FIG. 7). In this process, the asset management server 2 first compares the release module management table identified by the revision number targeted for release with the release module management table identified by the modification number not targeted for release (S21).

  If the module recorded in the release module management table identified by the revision number targeted for release is not older than the module of the same name recorded in the release module management table not subject to release (NO in S22), the asset management server 2 outputs error information and ends the process (S26).

  On the other hand, if the module recorded in the release module management table identified by the revision number targeted for release is older than the module of the same name recorded in the release module management table not subject to release (YES in S22), asset management The server 2 determines whether there is next data (S23). The following data exists when there is remaining data in the release module management table identified by the revision number of the release target or when there is a release module management table identified by the revision number of the next release target. .

  If there is the next data in the determination in S23, the asset management server 2 returns the control to S21. If it is determined in S23 that there is no next data, the asset management server 2 stores the update date of the module recorded in the release module management table identified by the revision number to be released and a file storing the module (for example, , The dates of modules waiting for the test in the integrated test environment) are compared (S24).

If the update date of the module recorded in the release module management table identified by the revision number to be leased is not older (NO in S25), the asset management server 2 outputs error information and performs processing Is finished (S26).

  On the other hand, when the update date of the module recorded in the release module management table identified by the revision number to be leased is older (YES in S25), the asset management server 2 determines whether or not there is the next data. Is determined (S27).

  If there is the next data in the determination in S27, the asset management server control is returned to S24. If it is determined in S27 that there is no next data, the asset management server 2 displays a process completion message and ends the process (S28).

  As described above, according to the information system, it is possible to mechanically prevent a release failure when a plurality of update operations for a program product are performed and released in parallel.

  That is, it is possible to detect a case where a module older than the module already included in the already-released program product is included in the later-generation program product and released.

  In addition, in an integrated compilation environment, that is, an environment in which the source program of a specific module or all program products is compiled in one area (for example, a folder or a directory), it is tested after being modified to the program product to be released. When there is a possibility that a portion (load module or object module) corresponding to an incomplete source program is included, a module that may include such a portion can be detected.

<Modification>
In the above embodiment, the information system is configured by the web server 1, the asset management server 2, the development server 3, the compilation server, the release server 4, the test server, etc. and the terminal 10. However, the implementation of the present invention is not limited to such a computer configuration.

  For example, the server functions may be provided by a single server. Conversely, each server may be configured by a plurality of computers. Furthermore, the functions of the information system may be realized in a stand-alone environment using a single computer.

  In the above embodiment, when the release module management table to be released and the release module management table to be released are not compared, and there is no failure, the update date of the module recorded in the release module management table to be released is further updated. And the update date of the file that stores the module.

  However, the implementation of the present invention is not limited to such a procedure. For example, the update date may be compared between the file of the module to be released and the file of the module waiting for the test (including during the test) in the integrated test environment. That is, in the release module management table, the revision number and the file name storing the module included in the revision number may be recorded, and the update dates may be compared between the files.

In the above embodiment, a group of correction work and update work for a program product is performed as a correction number. A version level (generation) is configured by combining the results of a plurality of correction operations and the results of update operations. The level down check is performed with the revision number of the release target. Correction work and correction No. This was done by comparing the modification date of the corresponding module with the modification work.

  However, the revision No. And the revision number that is not subject to release. The modification date of the corresponding module may be compared between the generation to be released and the generation not to be released, instead of comparing the modification date of the corresponding module.

  That is, the correction No. Instead of comparing the modules for each correction operation specified by the above, the corresponding modules may be compared between the generations of program products. For example, if a module of a previously released generation program product has a newer update date than a corresponding module of a later released generation program product, a predetermined process is executed as a level down. You just have to do it.

<Computer-readable recording medium>
A program that causes a computer to realize any of the above functions can be recorded on a computer-readable recording medium. The function can be provided by causing the computer to read and execute the program of the recording medium.

  Here, the computer-readable recording medium refers to a recording medium in which information such as data and programs is accumulated by electrical, magnetic, optical, mechanical, or chemical action and can be read from a computer. Examples of such a recording medium that can be removed from the computer include a floppy (registered trademark) disk, a magneto-optical disk, a CD-ROM, a CD-R / W, a DVD, a DAT, an 8 mm tape, and a memory card. .

  Further, there are a hard disk, a ROM (read only memory), and the like as a recording medium fixed to the computer.

<Data communication embodied in carrier wave>
The program can be stored in a hard disk or memory of a computer and distributed to other computers through a communication medium. In this case, the program is transmitted through a communication medium as a data communication signal embodied by a carrier wave. And the said function can be provided to the computer which received the distribution.

  Here, the communication medium may be a wired communication medium, for example, metal cables including a coaxial cable and a twisted pair cable, an optical communication cable, or the like, or a wireless communication medium, for example, satellite communication or terrestrial radio communication.

  The carrier wave is an electromagnetic wave or light for modulating the data communication signal. However, the carrier wave may be a DC signal. In this case, the data communication signal has a baseband waveform without a carrier wave. Therefore, the data communication signal embodied in the carrier wave may be either a modulated broadband signal or an unmodulated baseband signal (corresponding to a case where a DC signal having a voltage of 0 is used as a carrier wave).

<Others>
Furthermore, this embodiment discloses the following invention.

(Appendix 1)
A program that causes a computer to detect defects when updating a program product that includes multiple modules.
Providing update identification information for identifying update work of the program product;
Recording the information for identifying the updated module and the information indicating the update time of the module together with the update identification information for each update operation;
A comparison step that compares the time of update against the target module of the update work to be released and the target module of the update work not to be released,
And a step of instructing execution of predetermined processing when an update time of a module to be released is newer than an update time of a module not to be released corresponding to the module.

(Appendix 2)
Further comprising the step of accessing such a file storing modules identified and updated for each update operation and referring to the update time of the file;
The program according to claim 1, wherein in the comparison step, at least one of a module to be released or a module not to be released is compared with an update time of the module based on an update time referenced from a file.

(Appendix 3)
The program according to attachment 1 or 2, wherein the predetermined process is a release postponement of a program product to be released.

(Appendix 4)
The program according to claim 1 or 2, wherein the predetermined process is a release promotion process of a program product that is an unscheduled program product and includes a module older than the module to be released.

(Appendix 5)
A program that causes a computer to detect defects when updating a program product that includes multiple modules.
Providing generation identification information for identifying each update generation of the program product;
For each update generation, recording information identifying the updated module and information indicating the update time of the module together with the generation identification information;
A comparison step for comparing the update points of the modules that are updated in the update generation to be released and the update generation not to be released;
And a step of instructing execution of predetermined processing when an update time of a module to be released is newer than an update time of a module not to be released corresponding to the module.

(Appendix 6)
A method in which a computer detects a defect when updating a program product including a plurality of modules.
Providing update identification information for identifying update work of the program product;
Recording the information for identifying the updated module and the information indicating the update time of the module together with the update identification information for each update operation;
A comparison step that compares the time of update against the target module of the update work to be released and the target module of the update work not to be released,
Instructing execution of a predetermined process when an update time of a module to be released is newer than an update time of a module not to be released corresponding to the module.

(Appendix 7)
A method in which a computer detects a defect when updating a program product including a plurality of modules.
Providing generation identification information for identifying each update generation of the program product;
For each update generation, recording information identifying the updated module and information indicating the update time of the module together with the generation identification information;
A comparison step for comparing the update points of the modules that are updated in the update generation to be released and the update generation not to be released;
Instructing execution of a predetermined process when an update time of a module to be released is newer than an update time of a module not to be released corresponding to the module.

(Appendix 8)
A management device that detects defects when updating a program product that includes multiple modules.
Means for providing update identification information for identifying update work of the program product;
Means for recording information for identifying an updated module and information indicating an update time of the module together with the update identification information for each update operation;
A comparison means for comparing the update points of the target module of the update work scheduled for release and the target module of the update work not planned for release
A management device comprising: means for instructing execution of a predetermined process when an update time of a module to be released is newer than an update time of a module not to be released corresponding to the module.

(Appendix 9)
A management device that detects defects when updating a program product that includes multiple modules.
Means for providing generation identification information for identifying each update generation of the program product;
Means for recording, for each update generation, information identifying the updated module and information indicating the update time of the module together with the generation identification information;
A comparison means for comparing the update points of modules updated in the update generation to be released and the update generation not to be released;
A management device comprising: means for instructing execution of a predetermined process when an update time of a module to be released is newer than an update time of a module not to be released corresponding to the module.

A diagram showing an example of a failure when a program product is released The figure which shows the principle of the information system which concerns on one embodiment of this invention System configuration diagram of information system Data flow diagram of information system Diagram showing the operational flow when modifying a program product Diagram showing the operational flow at release Flow chart showing modified module release process Flowchart showing details of level down prevention check process (S2 in FIG. 7)

Explanation of symbols

1 Web server 2 Asset management server 3 Development server (compile server)
4 Release server (test server)
10 Terminal 19 Level down check screen 19
21 Original

Claims (4)

A level down detection program for detecting a level down in a release of a computer program composed of a plurality of modules to a user,
Computer
In a plurality of release module management tables respectively corresponding to a plurality of update operations performed on the computer program, update operation information for specifying the update operation and one or more modules constituting the version-level computer program are specified. Storage means for associating and storing a module name and update date and time information for specifying the date and time when each module was compiled and updated;
Accepting means for accepting from the operator version level information that identifies the version level to be released to the user;
Display means for displaying a list of update work information belonging to the version level specified by the version level information received by the receiving means;
Acquisition means for acquiring update work information selected by the user from the list displayed by the display means;
Release module management including the same module name as the release module management table of the update work specified by the update work information acquired by the acquisition means, and including update date / time information specifying a date / time older than the update date / time information of the module Search means for searching the table, and
A level-down detection program that functions as an output unit that outputs error information when the search unit detects any release module management table. A level down detection method for detecting a level down in a release of a computer program composed of a plurality of modules to a user,
Computer
In a plurality of release module management tables respectively corresponding to a plurality of update operations performed on the computer program, update operation information for specifying the update operation and one or more modules constituting the version-level computer program are specified. A storage procedure for storing the module name and the update date and time information for specifying the date and time when each module was compiled and updated;
A procedure for accepting, from an operator, version level information for identifying a version level to be released to the user;
A display procedure for displaying a list of update work information belonging to the version level specified by the version level information received in the reception procedure;
An acquisition procedure for acquiring update work information selected by the user from the list displayed in the display procedure;
Release module management including the same module name as the release module management table of the update work specified by the update work information acquired in the acquisition procedure, and including update date / time information specifying a date / time older than the update date / time information of the module Search procedure for searching the table, and
An output procedure for outputting error information when any one of the release module management tables is detected in the search procedure. A management program for detecting defects when updating a computer program including a plurality of modules,
On the computer,
For each update operation of the computer program, update identification information for identifying the update operation, module identification information for identifying a module updated by the update operation, and update time information indicating the update time of the module And a recording step for recording in a table,
An accepting step for accepting designation to include in the release schedule update update information of update work in which a module to be provided to an end user's computer is updated among update identification information of the plurality of update works;
Update point information indicating the update point of the module identified by the update identification information specified to be included in the release schedule in the reception step, and an update not scheduled to be released that is not specified in the release schedule in the reception step A comparison step for comparing the update time information indicating the update time of the module specified by the identification information; and
As a result of the comparison in the comparison step, the update point of the module specified by the update identification information designated to be included in the release schedule is specified by the update identification information other than the release schedule for the same module. A management program that executes an output step of outputting an instruction to postpone the release of the computer program including the module related to the release schedule when newer than the time point. A management program for detecting defects when updating a computer program including a plurality of modules,
On the computer,
For each update operation of the computer program, update identification information for identifying the update operation, module identification information for identifying a module updated by the update operation, and update time information indicating the update time of the module And a recording step for recording in a table,
An accepting step for accepting designation to include in the release schedule update update information of update work in which a module to be provided to an end user's computer is updated among update identification information of the plurality of update works;
Update point information indicating the update point of the module identified by the update identification information specified to be included in the release schedule in the reception step, and an update not scheduled to be released that is not specified in the release schedule in the reception step A comparison step for comparing the update time information indicating the update time of the module specified by the identification information; and
As a result of the comparison in the comparison step, the update point of the module specified by the update identification information designated to be included in the release schedule is specified by the update identification information other than the release schedule for the same module. An output step for outputting a command for prompting the execution of a test is executed for a module whose update time is older than a module related to the release schedule among modules related to the non-release schedule when newer than the time point. Management program.

Images