JP2009295050A - Product management server, product management method and program - Google Patents

Abstract

When a product change occurs in system development, the inconsistency of the product in a rework operation caused by the change is reduced.
A deliverable management server 1 for managing deliverables created for each process, a deliverable management information storage unit for storing a process context of the deliverables created in each process, and a result The presence or absence of a change in the product should be monitored, and the product to be corrected should be corrected as confirmation order information based on the context information in the product information storage unit in accordance with the change in the product. A product change monitoring unit that sequentially extracts, and a product change notification unit that sequentially transmits a confirmation request for a product to be corrected to the user terminal based on the confirmation order information.
[Selection] Figure 1

Description

  The present invention relates to a product management server, a product management method, and a program.

In general, in system development, a product (requirement definition document, basic design document, detailed design document, function definition, etc.) in each process is created based on the product of the previous process. For example, the basic design document is created based on a requirement definition document that is a product of the previous process.
By the way, these deliverables frequently change due to various factors. In that case, a rework operation for correcting the product affected by this change occurs. For example, if a change occurs in a certain deliverable, if there is an effect on the deliverable created in the process before the deliverable (hereinafter referred to as the previous deliverable) It is necessary to update the previous deliverables. However, in actual system development, each deliverable does not correspond one-to-one, and there is a relationship between a plurality of documents.
In the technique described in Patent Document 1, it is set in advance (linked) to which deliverables a change of a certain product affects, and the range of influence when the change actually occurs (the affected product) ) Is specified.

FIG. 13 is a schematic diagram illustrating an example of a rework operation that occurs due to a change in a product.
In the example shown in this figure, a basic design document B is created based on the requirement definition document A. A detailed design document C and a detailed design document D are created based on the basic design document B. The function definition document E is created based on the detailed design document C and the detailed design document D.
Here, in the function definition document E, a case where the adopted OS is changed from Windows (registered trademark) to Linux and the language used is changed from Java (registered trademark) to C language will be described.
In response to this change, it is necessary to change the adopted OS and language used in the detailed design document C. Further, in the detailed design document D, in addition to the adopted OS and the language used, the adopted DB needs to be changed from MySQL to DB2. Accordingly, in the basic design document B, it is necessary to change the adopted OS, the language used, and the adopted DB under the influence of the change of the detailed design document C and the detailed design document D.
The basic design document B includes a plurality of deliverables (hereinafter referred to as post-delivery products) created in a process subsequent to the deliverable. Therefore, the basic design document B is affected by the change of a plurality of deliverables (detailed design document C and detailed design document D). Hereinafter, a product having a plurality of subsequent products such as the basic design document B is referred to as a branch source product.
In the above-described example, after the detailed design document C and the detailed design document D are completely changed, the basic design document B must be changed. If only the change of the detailed design document C is completed, if the basic design document B is changed, the influence of the change of the detailed design document D cannot be taken into account, and it is adopted in the basic design document B. A product inconsistency that a change in DB is lost occurs.
JP 2007-18334 A

However, since the technique described in Patent Document 1 does not consider the change order of the deliverables in the rework work that occurs due to the change of the deliverables, there is a possibility that the inconsistencies of the deliverables as described above may occur. There is a problem that there is.
The present invention has been made in view of the above points, and its purpose is to reduce the inconsistency of deliverables in rework work caused by the change when the change of the deliverable in system development occurs. The object is to provide a deliverable management server, deliverable management method and program.

  The present invention has been made to solve the above-described problems, and one aspect of the present invention is a deliverable management server that manages deliverables created for each process, and the results created in each process Deliver management information storage unit for storing the context between product processes, and monitoring the presence or absence of changes in the deliverables, and the deliverables to be checked for correction along with the change of the deliverables Based on the context information of the information storage unit, the product change monitoring unit that extracts the order of the correction as the confirmation order information, and the product to be confirmed to be corrected to the user terminal based on the confirmation order information A deliverable change notification section for sequentially sending confirmation requests;

  Further, according to one aspect of the present invention, in the deliverable management server, the deliverable update monitoring unit further determines that the deliverable confirmed to be changed is based on the confirmation request transmitted by the deliverable change notification unit. If the result is a changed product, a product to be newly confirmed for correction is extracted from the product storage unit, and the confirmation order information is updated.

  Further, according to an aspect of the present invention, in the deliverable management server, the deliverable update monitoring unit sequentially extracts the deliverables of the previous process based on the deliverables that have changed, and then performs a post process. It is characterized by sequentially extracting the deliverables along the process.

  Further, according to one aspect of the present invention, in the product management server, the product information storage unit further stores the importance of the relationship between the product and the product in the context of the product. The product update monitoring unit extracts confirmation order information based on the importance.

  Also, one aspect of the present invention is a deliverable management method for managing deliverables created for each process, and a deliverable management information storage unit that stores the context of the deliverables created in each process The product management server including the product monitors whether or not the product has been changed, and, according to the change of the product, determines the product to be confirmed based on the context information of the product information storage unit. A step of extracting the order of correction as confirmation order information, and a step of sequentially transmitting a confirmation request for a product to be confirmed to be corrected to the user terminal based on the confirmation order information by the deliverable management server And a product management method characterized by comprising:

  A program for managing deliverables created for each process, and changing the deliverables to a computer with a deliverable management information storage unit that stores the context of the deliverables created in each process. In addition to monitoring the presence / absence of the product, the product to be corrected is extracted as the confirmation order information in the order to be corrected based on the context information of the product information storage unit in accordance with the change of the product. And a step for sequentially transmitting a confirmation request for a product to be confirmed for correction to a user terminal based on the confirmation order information.

  According to the present invention, the context between the processes of the products created in each process is stored, and when the product changes, the products to be corrected are extracted in the order of update. Therefore, the worker can update the deliverables according to the extracted order. Thereby, when the change of the deliverable in system development arises, the mismatch of the deliverable in the rework work which arises by the change can be reduced. In addition, it is possible to suppress rework by rework due to product mismatch.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
[First Embodiment]
FIG. 1 is a block diagram showing a configuration of a product management system according to an embodiment of the present invention. The product management system includes a product management server 1 and a plurality of user terminals 2. The user terminal 2 is a terminal used by a worker who creates or updates a product. The user terminal 2 includes a document editing unit 21 that edits a product.
The product management server 1 includes a product management unit 11, a product update monitoring unit 12, a product change notification unit 13, a worker DB (database) 14, and a product management DB (database) 15 (product). Management information storage unit), product storage unit 16, history DB (database) 17, and confirmation order DB (database) 18.

  The deliverable management unit 11 manages the deliverables generated in each process in system development. In the present embodiment, the deliverable is a document generated in each process such as a requirement definition document, basic design document, detailed design document, and function definition document. When receiving the new product registration request together with the product from the user terminal 2, the product management unit 11 stores the received product in the product storage unit 16. At this time, the product management unit 11 generates a product ID for uniquely identifying the product, and stores the product ID in the product management DB 15 in association with the stored product. When the product management unit 11 receives a product update request together with the product from the user terminal 2, the product management unit 11 stores the received product in the product storage unit 16. At this time, the product management unit 11 replaces the product corresponding to the product ID included in the product update request of the product management DB 15 with the newly stored product.

  The deliverable update monitoring unit 12 manages the update status of deliverables. When the deliverable change occurs, the deliverable update monitoring unit 12 extracts the deliverables that affect the change of the deliverable in the order to be updated based on the relationship between the deliverables. Further, the product update monitoring unit 12 generates a confirmation order table (confirmation order information) indicating whether or not the extracted product has been confirmed by the worker, and stores the confirmation order table in the confirmation order DB 18. When the confirmation order DB 18 is updated, the product change notification unit 13 transmits a product change notification to the user terminal 2 based on the confirmation order table.

FIG. 2 is a schematic diagram illustrating an example of the relationship between deliverables in the present embodiment.
The deliverables A001 to A009 shown in this figure are stored in the deliverable storage unit 16. In the example shown in this figure, the subsequent products of the product A001 are the product A002 and the product A003. The previous product of the product A002 is the product A001, and the subsequent product is the product A004. The previous product of the product A003 is the product A001, and the subsequent products are the product A004 and the product A005. The previous products of the product A004 are the product A002 and the product A003, and the subsequent products are the product A006 and the product A007. The previous product of the product A005 is the product A003, and there is no subsequent product. The previous product of the product A006 is the product A004, and there is no subsequent product. The previous product of the product A007 is the product A004, and the subsequent products are the product A008 and the product A009. The previous product of the product A008 is the product A007, and there is no subsequent product. The previous product of the product A009 is the product A007, and there is no subsequent product.

FIG. 3 is a schematic diagram illustrating a data structure and a data example of a worker table stored in the worker DB 14 in the present embodiment.
As shown in the figure, the worker table is two-dimensional tabular data composed of rows and columns, and has columns of items of user ID, mail address, and belonging group ID. The primary key of this worker table is a user ID. Each row of the worker table exists for each worker. The user ID is an identification number for uniquely identifying the worker. The email address is the worker's email address. The belonging group ID is an identification number of the group to which the worker belongs.

FIG. 4 is a schematic diagram illustrating a data structure and a data example of a product management table stored in the product management DB 15 in the present embodiment.
The deliverable management table stores the context of the process in which each deliverable in system development is generated. As shown in the figure, the deliverable management table is a two-dimensional tabular data composed of rows and columns. The deliverable ID, the previous deliverable ID, the subsequent deliverable ID, the path, the creator, It has a column for each item of change date and time. The primary key of this deliverable management table is the deliverable ID. Each row of the deliverable management table exists for each deliverable. The product ID is an identification number for uniquely identifying the product. The previous product ID is the product ID of the previous product. The post product ID is a product ID of the post product. The path is an address where the deliverable is stored. The creator is the user ID of the creator of the deliverable. The change date / time is the date / time when the deliverable is updated. In the column of the previous product ID and the subsequent product ID, “null” represents that there is no corresponding product.

FIG. 5 is a schematic diagram illustrating a data structure and a data example of a history table stored in the history DB 17 in the present embodiment.
The history table is a table for recording a product update history. As shown in the figure, the history table is a two-dimensional tabular data composed of rows and columns, and includes columns for each item of change identification ID, deliverable ID, path, and change date / time. Yes. The change identification ID is an identification number for uniquely identifying the update content. The product ID is a product ID of the updated product. The path is an address that stores the updated product. The change date is the date when the deliverable was updated.

FIG. 6 is a schematic diagram illustrating a data structure and a data example of a confirmation order table stored in the confirmation order DB 18 in the present embodiment.
The confirmation order table is a table generated by the product update monitoring unit 12 when the product is changed. As shown in the figure, the confirmation order table is data in a two-dimensional tabular format composed of rows and columns, and columns of items of a product ID, a link source product ID, a direction, and a confirmed flag. have. The primary key of this confirmation order table is the product ID. Each row of the confirmation order table exists for each deliverable. The link source product ID is the product ID of the product just before the link that connects the changed product to the product. The direction indicates whether the product is a pre-product or a post-product with respect to the link-source product. “Pre” represents that the deliverable is a previous deliverable of the link-source deliverable. “Post” represents that the deliverable is a subsequent deliverable of the link-source deliverable. The confirmation flag is a flag indicating whether or not the worker has confirmed the deliverable. When the confirmation flag is “ON”, it indicates that the worker has confirmed. In the figure, “◯” indicates that the confirmation flag is “ON”.

FIG. 7 is a flowchart showing the flow of the product registration process of the product management server 1 in this embodiment.
The user terminal 2 transmits the product created by the worker to the product management server 1 via the network together with a new product registration request. The process shown in FIG. 7 starts when the product management server 1 receives a new product registration request together with a product. The new product registration request is a registration request for a newly created product.
First, in step S <b> 1, the product management unit 11 requests the previous product ID of the received product and the user ID of the worker from the user terminal 2. Specifically, the deliverable management unit 11 displays an input screen for the previous deliverable ID and the user ID on the screen of the user terminal 2. At this time, the product management unit 11 may read all product IDs from the product management table of the product management DB 15 and display the list on the screen of the user terminal 2. Thereby, the user terminal 2 can select the previous product ID from the list.
In next step S <b> 2, the product management unit 11 determines whether or not the previous product ID and the user ID are received from the user terminal 2. When the previous product ID and the user ID are received, the process proceeds to the next step S3. On the other hand, if not received, the process returns to step S2.

  In the next step S3, the product management unit 11 generates a product ID for uniquely identifying the received product. In the next step S <b> 4, the product management unit 11 stores the received product in the product storage unit 16. In the next step S5, the product management unit 11 associates the generated product ID, the received previous product ID, the product path, the received user ID, and the current date and time with the product management DB 15. To the product management table. In addition, the product management unit 11 adds the generated product ID to the subsequent product ID of the received previous product ID. Specifically, for example, when the product A009 shown in the product management table of FIG. 4 is registered, the product management unit 11 records the record {A009, A007, null, ¥¥ project ¥ in the product management table. 0901. doc, TA07KA, 2008/5/2 16:30}. Further, the deliverable management unit 11 adds “A009” to the succeeding product ID of the deliverable A007, which is the previous deliverable of the deliverable A009. As a result, the deliverable is registered in the deliverable management server 1.

FIG. 8 is a flowchart illustrating an example of the flow of the product change process of the product management server 1 in the present embodiment.
The process shown in this figure starts when a product update request is received together with a product from the user terminal 2. The product update request is a product update request including the product ID. The product is changed by the document editing unit 21 of the user terminal 2. At this time, the user terminal 2 transmits a product list acquisition request to the product management server 1 in order to change the product. The deliverable management server 1 generates a list of deliverable IDs with reference to the deliverable management DB 15 in the deliverable management unit 11 and transmits the generated list to the user terminal 2. The user terminal 2 selects a product from the received list and transmits the selected result to the product management server 1. The deliverable management unit 11 of the deliverable management server 1 refers to the worker DB 14 and determines whether or not the worker has the correct authority to update the selected deliverable. Whether or not it has the correct authority is determined to have the correct authority when the worker is in the same group as the creator of the deliverable. When it is determined that the user has the correct authority, the product management unit 11 acquires the product from the product storage unit 16 and transmits the product to the user terminal 2. Thereby, the user terminal 2 can change the deliverable.

First, in step S <b> 101, the product management unit 11 stores the received product in the product storage unit 16. In the next step S102, the product management unit 11 updates the product management table of the product management DB 15. Specifically, the deliverable management unit 11 rewrites the path corresponding to the received deliverable with the deliverable path stored in step S101. Further, the deliverable management unit 11 rewrites the update date and time corresponding to the received deliverable to the current time.
In the next step S103, the product update monitoring unit 12 determines whether or not the received product update request includes a change identification ID. If the change identification ID is included, the process proceeds to the next step S109. On the other hand, if the change identification ID is not included, the process proceeds to step S104.
In step S104, the product update monitoring unit 12 generates a change identification ID. In next step S105, the product update monitoring unit 12 registers the generated change identification ID and the received product in the history table in association with each other.

  Next, in step S107, the product update monitoring unit 12 generates a confirmation order table. Details of the generation process of the confirmation order table will be described later. In the next step S108, the deliverable change notification unit 13 transmits a confirmation request notification to the user terminal 2 and ends the process. Specifically, the product change notification unit 13 acquires the top product ID of the confirmation order table, and refers to the product management table to identify the creator of the product. Then, the product change notification unit 13 transmits a confirmation request notification including the acquired product ID, the product ID of the changed product, and the change identification ID to the user terminal 2 of the identified creator.

  On the other hand, in step S109, the deliverable update monitoring unit 12 registers the received change identification ID and the received deliverable in the history table in association with each other. In the next step S110, merge processing of the confirmation order table is performed. Details of the merge processing of the confirmation order table will be described later. In the next step S111, confirmation processing of the confirmation order table is performed. Details of the confirmation processing of the confirmation order table will be described later.

FIG. 9 is a schematic diagram for explaining the generation process of the confirmation order table in the present embodiment. The example shown in this figure is a confirmation order table when the deliverable A004 is changed.
First, the product update monitoring unit 12 performs forward extraction. Specifically, the product update monitoring unit 12 first extracts all previous products for the updated product A004. The previous deliverables of the deliverable A004 are deliverables A002 and A003. The deliverable update monitoring unit 12 stores the extracted records of the previous deliverables A002 and A003 in the confirmation order table in order. At this time, the product update monitoring unit 12 sets the link source product ID as a product A004.
Next, the product update monitoring unit 12 extracts the previous products of the extracted previous products A002 and A003, respectively. The previous product of the product A002 is the product A001. The deliverable update monitoring unit 12 inserts the record of the deliverable A001 immediately after the deliverable A002. At this time, the product update monitoring unit 12 sets the link source product ID as a product A002. On the other hand, the previous product of the product A003 is the product A001. The deliverable update monitoring unit 12 inserts the record of the deliverable A001 immediately after the record of the deliverable A003. At this time, the product update monitoring unit 12 sets the link source product ID as a product A003. The deliverable update monitoring unit 12 repeats this process until there are no previous deliverables.

Since the deliverable A001 does not have a previous deliverable, the deliverable update monitoring unit 12 next performs backward extraction. Specifically, the deliverable update monitoring unit 12 first extracts all the deliverables after the deliverable A004. Subsequent deliverables of deliverables A004 are deliverables A006 and A007. The product update monitoring unit 12 stores the extracted records of the products A006 and A007 in the confirmation order table in order. At this time, the product update monitoring unit 12 sets the link source product ID as a product A004.
Next, the product update monitoring unit 12 extracts the subsequent products A006 and A007 that have been extracted. There are no deliverables after deliverable A006. Subsequent deliverables of deliverables A007 are deliverables A008 and A009. The deliverable update monitoring unit 12 inserts records of deliverables A008 and A009 immediately after the deliverable A007. At this time, the product update monitoring unit 12 sets the link source product ID as a product A007. The deliverable update monitoring unit 12 repeats this process until there are no more deliverables. Thereby, the table shown in FIG. 9A is generated.

  When the backward extraction is completed, the product update monitoring unit 12 determines whether or not a record having the same product ID is stored. In the example shown in FIG. 9A, the deliverable A001 is duplicated. In this case, the product update monitoring unit 12 deletes the previously stored record and adds the link source product ID of the deleted record to the link source product ID of the record stored later. As a result, the confirmation order table shown in FIG. 9B is generated.

FIG. 10 is a flowchart illustrating an example of the flow of the confirmation order table confirmation process of the product management server 1 in the present embodiment.
The process shown in this figure is a process corresponding to step S111 described above. The process shown in this figure is also performed when a confirmation notification is received from the user terminal 2. The confirmation notification is a notification indicating that the worker has confirmed the change, including the product ID. The deliverable update request including the confirmation notification and the change identification ID is a response to the confirmation request.
First, in step S201, the product update monitoring unit 12 sets the confirmation flag of the confirmation order table corresponding to the received product ID to “ON”. In the next step S201, the product update monitoring unit 12 determines whether or not all the product confirmation processing has been completed. Specifically, when the confirmation flags of all the deliverables in the confirmation order table are “ON”, it is determined that all the confirmation processes are completed. When all the confirmation processes are completed, the process ends. On the other hand, if not completed, the process proceeds to step S203. In step S203, the product change notification unit 13 acquires the product ID of the product to be updated next from the confirmation order table. Specifically, the deliverable change notification unit 13 sets a deliverable for which the confirmation process has not been completed and that is stored in the forefront of the confirmation order table to be updated next. In the next step S204, the deliverable change notification unit 13 refers to the deliverable management table and specifies the creator of the deliverable to be updated next. Then, the deliverable change notification unit 13 sends a confirmation request notification including the deliverable ID of the deliverable to be updated, the deliverable ID of the changed deliverable, and the change identification ID to the user terminal 2 of the identified creator. Send.

FIG. 11 is a schematic diagram for explaining the confirmation order table merge process of the deliverable management server 1 in the present embodiment.
The process shown in this figure is a process corresponding to step S110 described above. In the example illustrated in FIG. 11, a process when the deliverable A003 is changed in a state where the confirmation process for the change of the deliverable A004 is not completed is illustrated. FIG. 11A is a confirmation order table that has already been generated. FIG. 11B is a confirmation order table newly generated by the process shown in FIG. 9 by changing the deliverable A003. FIG. 11C shows the result of merging FIG. 11A and FIG. 11B.
The deliverable update monitoring unit 12 inserts the confirmation order table in FIG. 11B immediately after the record A003 in FIG. At this time, the deliverable update monitoring unit 12 deletes the record A003 in FIG. Next, the deliverable update monitoring unit 12 deletes the record in which the confirmation flag is already “ON” in FIG. 11A among the newly inserted records. In the example shown in FIG. 11C, since the confirmation flags of the records A004 and A001 are already “ON”, the newly inserted record is deleted. Next, when there are duplicate records, the deliverable update monitoring unit 12 deletes the previous record and sets the link source artifact ID of the deleted record as the link source artifact ID of the subsequent record. to add. In this way, the confirmation order table shown in FIG. 11C is updated.

Next, a process when the confirmation process is not completed within a preset time will be described.
The deliverable change notification unit 13 first refers to the confirmation order table and obtains a deliverable ID whose confirmation flag is not “ON” even if a preset time has elapsed from the transmission time of the confirmation request notification. To do. Next, the deliverable change notification unit 13 specifies the creator of the deliverable with reference to the deliverable management table. Then, the deliverable change notification unit 13 extracts workers who belong to the same group as the creator identified with reference to the worker table. Finally, the deliverable change notification unit 13 transmits the confirmation request notification again to the user terminals 2 of all the extracted workers. This can prompt the operator to confirm again. In this embodiment, the confirmation request notification is sent again to all workers who belong to the same group as the creator. However, the authority information is stored in the worker table and belongs to the same group as the identified creator. Then, a confirmation request notification may be transmitted to a worker having higher authority.

Next, the deliverable update cancellation process will be described.
When the worker confirms the deliverable by the notice of confirmation request from the deliverable change notifying unit 13, the update can be canceled if a series of update processing is not permitted for some reason. In this case, the user terminal 2 transmits a cancel request including the change identification ID and the product ID to the product management server 1 by the operator's operation. When receiving the cancel request, the product management unit 11 of the product management server 1 refers to the history table and acquires the path using the received change identification ID and product ID as a key. Then, the deliverable management unit 11 performs a rollback process in which the path corresponding to the deliverable ID in the deliverable management table is replaced with the acquired path. Thereby, the update can be canceled.

As described above, according to the present embodiment, when a change in a product occurs, the product update monitoring unit 12 extracts a product that affects the change in an order to be updated, and generates a confirmation order table. Further, the deliverable change notification unit 13 transmits a confirmation request notification to the user terminal 2 based on the confirmation order table. Since the worker updates the deliverables in the notified order, when the deliverable changes in the system development occur, it is possible to reduce the inconsistency of the deliverables in the rework operation. Thereby, it is possible to suppress rework by rework due to product mismatch.
In addition, when the confirmation process is not completed within a preset time, the confirmation request notification is performed again, so that the operator can be prompted to confirm again, and rework can be prevented from being delayed.

[Second Embodiment]
Next, the deliverable management server 1 according to the second embodiment of the present invention will be described.
In the first embodiment, in the case of a product with many branches, the product cannot be updated or confirmed unless all the link source products are confirmed. Therefore, when there are many branches, it may take time to update all the deliverables. Therefore, the product management server 1 according to the present embodiment generates a confirmation order table in consideration of the importance of the relationship between the products.

First, the product registration process will be described.
When the product management unit 11 of the product management server 1 receives the new product registration request, the importance level of the relationship between the product and the previous product received together with the previous product ID and the user ID in the user terminal 2 Request. Then, the product management unit 11 stores the related importance received from the user terminal 2 in the product management DB 15.
FIG. 12 is a schematic diagram illustrating a data structure and a data example of an importance table stored in the product management DB 15 in the present embodiment.
The importance table stores the importance of the relationship between the product of the previous process and the product of the subsequent process. As shown in the figure, the importance table is a two-dimensional tabular data composed of rows and columns, and has columns for each item of the product ID, the previous product ID, and the importance. . The primary key of this importance table is the product ID and the previous product ID. The importance indicates the importance of the relationship between the deliverable and the previous deliverable. The importance is represented by a positive integer from 1 to N. The greater the importance, the lower the importance. N is an integer of 2 or more.

Next, the generation process of the confirmation order table will be described.
When the product update monitoring unit 12 performs forward extraction, the product update monitoring unit 12 stores the results in the confirmation order table in order from the route connected by the previous product having the higher importance. Similarly, when the product update monitoring unit 12 performs backward extraction, the product update monitoring unit 12 stores in the confirmation order table in order from the route connected by the post-product having the higher importance. Thereby, it is possible to perform confirmation processing from a product that is more relevant to the changed product.
Since other configurations are the same as those of the first embodiment, the description thereof is omitted.

  Thus, according to the present embodiment, the confirmation order table is generated based on the importance of the relationship between the deliverables. As a result, confirmation processing can be performed from a product with higher relevance to the changed product, and the change can be handled in a shorter time.

Further, a program for realizing the function of the deliverable management server 1 shown in FIG. 1 is recorded on a computer-readable recording medium, and the program recorded on the recording medium is read into a computer system and executed. The deliverable management process may be performed. Here, the “computer system” may include an OS and hardware such as peripheral devices.
Further, the “computer system” includes a homepage providing environment (or display environment) if a WWW system is used.
The “computer-readable recording medium” means a flexible disk, a magneto-optical disk, a ROM, a writable nonvolatile memory such as a flash memory, a portable medium such as a CD-ROM, a hard disk built in a computer system, etc. This is a storage device.

Further, the “computer-readable recording medium” refers to a volatile memory (for example, DRAM (Dynamic DRAM)) in a computer system that becomes a server or a client when a program is transmitted via a network such as the Internet or a communication line such as a telephone line. Random Access Memory)), etc., which hold programs for a certain period of time.
The program may be transmitted from a computer system storing the program in a storage device or the like to another computer system via a transmission medium or by a transmission wave in the transmission medium. Here, the “transmission medium” for transmitting the program refers to a medium having a function of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line.
The program may be for realizing a part of the functions described above. Furthermore, what can implement | achieve the function mentioned above in combination with the program already recorded on the computer system, and what is called a difference file (difference program) may be sufficient.

  As described above, the embodiment of the present invention has been described in detail with reference to the drawings. However, the specific configuration is not limited to the above, and various design changes and the like can be made without departing from the scope of the present invention. It is possible to

  For example, in this embodiment, the confirmation request notification is transmitted to all the products extracted in the confirmation order table, but when the confirmed operator determines that the correction is minor, You may comprise so that a confirmation process may be completed as a confirmation is unnecessary. In this case, the user terminal 2 transmits to the deliverable management server 1 a confirmation-unnecessary notification including the deliverable ID that has been determined not to be confirmed by the operator's operation. When the product update monitoring unit 12 of the product management server 1 receives the confirmation unnecessary notification, the product update monitoring unit 12 sets the confirmation flag corresponding to the received product ID in the confirmation order table to “ON” and sets the product ID to the link source. The confirmation flag corresponding to the product ID of the product ID is set to “ON”. Further, the deliverable update monitoring unit 12 performs the same process for the deliverable ID having the deliverable ID with the confirmation flag “ON” as the link source deliverable ID. The deliverable update monitoring unit 12 repeats this process until there is no deliverable ID having the deliverable ID with the confirmation flag set to “ON” as the link source deliverable ID. Note that this processing is not performed for a product having a plurality of link source product IDs.

  In this embodiment, confirmation is performed for each file, but a plurality of items may be included in one file, and a product ID may be assigned to each item. In this case, since the influence range is divided into a small number, the confirmation work becomes easy.

It is a block diagram which shows the structure of the product management system by 1st Embodiment. It is the schematic which shows an example of the relationship of the deliverable in this embodiment. It is the schematic which shows the data structure of the worker table memorize | stored in worker DB in this embodiment, and a data example. It is the schematic which shows the data structure and data example of a product management table memorize | stored in product management DB in this embodiment. It is the schematic which shows the data structure and data example of the log | history table memorize | stored in log | history DB in this embodiment. It is the schematic which shows the data structure and data example of a confirmation order table memorize | stored in confirmation order DB in this embodiment. It is a flowchart which shows the flow of the product registration process of the product management server in this embodiment. It is a flowchart which shows an example of the flow of the product change process of the product management server in this embodiment. It is the schematic for demonstrating the production | generation process of the confirmation order table in this embodiment. It is a flowchart which shows an example of the flow of the confirmation order table confirmation process of the deliverable management server in this embodiment. It is the schematic for demonstrating the confirmation order table merge process of the deliverable management server in this embodiment. It is the schematic which shows the data structure and data example of the importance level table which are memorize | stored in the product management DB in this embodiment. It is the schematic which showed an example of the rework work which generate | occur | produces by the change of a deliverable.

Explanation of symbols

    1 ... product management server 2 ... user terminal 11 ... product management unit 12 ... product update monitoring unit 13 ... product change notification unit 14 ... worker DB 15 ... product management DB 16 ... product storage unit 17 ... History DB 18 ... Confirmation order DB

Claims (6)

A deliverable management server for managing deliverables created for each process,
A deliverable management information storage unit for storing the context between deliverables created in each process;
While monitoring the presence or absence of changes in the deliverables, the deliverables to be checked for correction are corrected as confirmation order information based on the context information in the deliverable information storage unit. A product change monitoring unit that extracts in power order;
Based on the confirmation order information, a deliverable change notification unit that sequentially transmits a confirmation request for a deliverable to be confirmed to the user terminal;
A product management server characterized by comprising: The deliverable update monitoring unit further updates a new product from the deliverable storage unit when the confirmed product is a product that has been changed based on the confirmation request transmitted by the product change notification unit. The deliverable management server according to claim 1, wherein a deliverable for which correction is to be confirmed is extracted and the confirmation order information is updated.   The deliverable update monitoring unit is characterized by sequentially extracting the deliverables of the subsequent process along the process after sequentially extracting the deliverables of the previous process based on the deliverable having changed. Item 3. The deliverable management server according to item 1 or 2. The deliverable information storage unit further stores the importance of the relationship between the deliverable and the deliverable in the context of the deliverable,
The deliverable management server according to any one of claims 1 to 3, wherein the deliverable update monitoring unit extracts confirmation order information based on the importance. A deliverable management method for managing deliverables created for each process, the deliverable management server having a deliverable management information storage unit for storing the context of the deliverables created in each process. The presence or absence of a change in the product should be monitored, and the product to be corrected should be corrected as confirmation order information based on the context information in the product information storage unit in accordance with the change in the product. Extracting in order;
The product management server sequentially transmits a confirmation request for a product to be confirmed for correction to a user terminal based on the confirmation order information;
A product management method characterized by comprising: A program for managing deliverables created for each process,
In a computer equipped with a product management information storage unit for storing the context between the processes of the product created in each process,
While monitoring the presence or absence of changes in the deliverables, the deliverables to be checked for correction are corrected as confirmation order information based on the context information in the deliverable information storage unit. Extracting in power order;
Sequentially transmitting confirmation requests for deliverables to be confirmed to the user terminal based on the confirmation order information;
A program for running

Images