JP2005309917A - Review support device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a review support device that facilitates the creation, maintenance, and management of a check list, while making it possible to efficiently conduct design reviews. <P>SOLUTION: The review support device includes a standard check item storage means for storing a plurality of standard check items for use in the review of software; an input means for inputting information on the functional specifications of software to be developed, design stage information available at the design stage of the software, and test information for use in the test of the software, as input information; a check item extraction means for extracting the check items necessary for the review of the software by collating the standard check items with the input information; and a check item storage means for storing the check items extracted by the check item extraction means. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a review support apparatus, and more particularly to a design review support apparatus for software development that automatically generates a checklist necessary for software development from a standard checklist, test information, and failure information.

  Conventionally, a program checklist automatic generation when developing software is configured to generate a checklist based on a program specification (for example, see Patent Document 1). Also, check items in the checklist are managed using the importance information input manually (see Patent Document 2).

JP-A-4-175925 JP-A-10-78890

  However, according to the conventional technology, in order to generate a checklist based on a program specification, every time new software is developed, the checklist for the software must be generated again from the beginning. There is a problem that it takes time. In the conventional technique, check items are also managed manually, and the management effort becomes enormous as the scale of software to be developed increases. As a result, there is a problem that test information and failure information cannot be objectively and accurately reflected in check items.

  Further, according to the conventional technology, the contents of the generated checklist are checked manually by a developer or the like, and the function of automatically checking the contents of the checklist is not provided. Therefore, when there are many check items, there is a problem that it takes a lot of trouble to check the contents of the check list.

  The present invention has been made in view of the above, and an object of the present invention is to obtain a review support device that can easily create and maintain a checklist and can perform an efficient design review. .

  In order to solve the above-described problems and achieve the object, a review support apparatus according to the present invention includes a standard check item storage unit that stores a plurality of standard check items used for software review, and development target software as input information. The input means for inputting the functional specification information, the design stage information obtained at the design stage of the development target software, and the test information used for testing the development target software, and the standard check items and the input information The check item extracting means for extracting check items necessary for the review of the development target software and the check item storage means for storing the check items extracted by the check item extracting means are provided.

  According to the present invention, the functional specification information of the development target software, the design stage information obtained at the design stage of the development target software, the test information used for testing the development target software, and the plurality of standards used for reviewing the software Using the check item, a check item used for reviewing the software to be developed is automatically generated. The generated check items are automatically stored in the database as a check list. In other words, in the present invention, the generation and maintenance of check items and check lists are automatically performed.

  In addition, since the check items of the software to be developed are generated using the functional specification 22, the design stage information 23, the test information 24, and the standard checklist database 21, each time new software is developed, There is no need to generate the checklist from the beginning, and the labor and time for generating the checklist are greatly reduced.

  Since the generation and maintenance of check items and checklists are performed automatically, even when the scale of the software to be developed increases, it is possible to easily and efficiently generate and maintain check items and checklists. In addition, information such as test information and failure information can be reflected in the checklist objectively and accurately.

  According to the present invention, a checklist for design information, test information and fault information and review of past software, and design information, test information and fault information and review of software currently under development are also provided. By linking checklists, checklists can be created and maintained easily and efficiently, and a review support device that enables efficient design reviews can be obtained. .

  Embodiments of a review support apparatus according to the present invention will be described below in detail with reference to the drawings. In addition, this invention is not limited to the following description, In the range which does not deviate from the summary of this invention, it can change suitably.

Embodiment 1 FIG.
FIG. 1 is a block diagram showing a configuration of a design review support apparatus for software development according to the first embodiment of the present invention. As shown in FIG. 1, the design review support apparatus 1 according to the present embodiment includes a control unit 11, a failure analysis unit 12, a check list creation unit 13, a check item addition unit 14, and a check list check unit 15. And an input / output device 19, a standard checklist database 21, and a checklist database 25. In addition, the project specification 22, design stage information 23, and test information 24 are input to the checklist creation unit 13 as input information.

  The control unit 11 controls the design review support apparatus 1. The failure analysis unit 12 analyzes the failure information database and extracts information that can be a check list. The check list creation unit 13 creates a check list suitable for a project under development using the functional specification 22, the design stage information 23, the test information 24, and the standard check list database 21. The check item adding unit 14 extracts check items from the failure information database and adds them to the standard checklist database 21 and the checklist database 25. The check list check unit 15 adds a check indicating that the correspondence has been completed to the check items in the check list. The input / output device 19 is a means for inputting / outputting information for allowing the control unit 11 of the design review support device 1 and the user of the design review support device 1 to have a conversation.

  The standard checklist database 21 is a database that stores a standard checklist 210 that summarizes standard check items necessary for review, independent of each development project. The functional specification 22 is a functional specification of a project that performs development to be reviewed. The design stage information 23 is current design stage information. The test information 24 is test information used for testing the current project. The check list database 25 is a database that stores a check list having the minimum necessary check items suitable for a project.

  As shown in FIG. 1, the failure management device 2 connected to the outside of the design review support device 1 is accumulated and organized in the failure management control unit 31 that controls the failure management device 2 and the failure management device 2. A failure information database 41, which is a database for storing failure information, is provided. The failure information database 41 corresponds to failure information of various past projects and projects currently in progress, and is a set of a plurality of databases. That is, for example, it is composed of a set of a plurality of databases such as an old project failure information database 1, an old project failure information database 2, an old project failure information database 3,.

  Note that the failure management apparatus 2, the failure management control unit 31 and the failure information database 41 included therein are not included in the constituent elements of the present invention. In the present invention, the information in the failure database 41 managed by the failure management apparatus 2 is shown in FIG. In FIG. 1, a solid line connecting the blocks indicates a data flow, and a broken line connecting the blocks indicates a control data flow.

  FIG. 2 shows items of information included in the standard checklist 210 stored in the standard checklist database 21 shown in FIG. The entire information items shown in FIG. 2 constitute one check item, and this set of check items constitutes one standard check list 210. As shown in FIG. 2, the standard check list 210 includes failure information serial numbers 211, serial numbers 212, check items 213, related functions 214, related design stage information 215, and other conditions 216.

  The failure information serial number 211 indicates the serial number of the failure information database 41 of the failure that is the basis of each check item. The serial number 212 is a non-overlapping serial number assigned to uniquely identify each check item. The check item 213 stores a description of the check item.

  The related function 214 is a related function indicating what function the check item 213 relates to in the project. Since the check item 213 can be related to a plurality of functions, the related function 214 includes a plurality of columns of related functions 1 to p (1 ≦ p) so that a plurality of related functions can be recorded.

  The related design stage information 215 is related design stage information that stores information about the design stage related to the check item 213. Since the check item 213 may be related to a plurality of design stages, a plurality of related design stage information 1 to related design stage information q (1 ≦ q) is recorded so that the related design stage information 215 can also record a plurality of related functions. It consists of the column of.

  The other condition 216 is information related to the check item 213 and stores information not included in the related function 214 and the related design stage information 215. Since the check item 213 may be related to a plurality of pieces of information, the other condition 216 includes a plurality of columns of other conditions 1 to other conditions r (1 ≦ r) so that a plurality of other conditions can be recorded.

  The configuration of the standard checklist 210 shown in FIG. 2 is an example showing information that the standard checklist database 21 should have at a minimum. Therefore, the standard checklist database 21 used in the present invention may be anything as long as it has information equivalent to or higher than the standard checklist database 21 shown in FIG.

  FIG. 3 shows items of information included in the check list 250 stored in the check list database 25 shown in FIG. One check item is constituted by the entire information items shown in FIG. 3, and a set of the check items is a check list 250. As shown in FIG. 3, the check list 250 includes a standard check list sequence number 251, a check list sequence number 252, a check item 253, a confirmation date 254, and other information 255.

  The standard checklist serial number 251 is a serial number indicating the serial number 212 in which the check item is numbered in the standard checklist database 21 from which the check item is extracted. The check list sequence number 252 is a non-overlapping sequence number assigned to uniquely identify each check item in each check list. The check item 253 stores a detailed description of the check item.

  The confirmation date and time 254 stores the date and time when the check item was confirmed. A description of a predetermined date and time in the confirmation date and time 254 indicates that the check item has been checked. If the contents of the other check items cannot be confirmed and are confirmed again after some correction or the like, it may be necessary to check the confirmed check items again. Therefore, the confirmation date 254 is composed of a plurality of fields of confirmation date 1 to confirmation date s (1 ≦ s) so that a plurality of confirmation dates can be recorded.

  In the other information 255, information included in the standard checklist database 21, function specifications 22, design stage information 23, test information 24, failure information database 41, and the like are stored as necessary. The other information 255 is used to enhance the contents of the check list, such as supplementary explanation of the contents of the check list. Further, the other information 255 also stores information when the check item adding unit 14 or the check list result totaling diagnosis unit 16 adds check items to the check list database 25 and updates / maintains the check list.

  The configuration of the check list 250 shown in FIG. 3 is an example showing the information that the check list database 25 should have at least, and has the information equivalent to or more than that of the check list database 25 shown in FIG. Anything can be used.

  FIG. 4 shows items of information included in the failure information database 41 shown in FIG. One piece of failure information is composed of the entire information items shown in FIG. The fault information database 41 is not within the scope of the present invention, but the present invention presupposes that at least the fault management apparatus 2 having the items shown in FIG. 4 exists. As shown in FIG. 4, the failure information database 41 includes a serial number 411, a failure name 412, an occurrence date / time 413, an occurrence function 414, a related function 415, an occurrence stage 416, a discovery stage 417, and other information 418. Yes.

  The serial number 411 is a non-overlapping serial number assigned to uniquely identify each piece of failure information. The failure name 412 stores a name indicating the content of the failure information that has occurred, a failure content, and a response content. The occurrence date / time and response date / time 413 are the date / time when the failure indicated by the failure name 412 occurred and the date / time when the response was completed. The occurrence function 414 indicates which function developed by the project has caused the failure indicated by the failure name 412.

  The related function 415 indicates to which function the failure indicated by the failure name 412 is related. In the related function 415, the failure indicated by the failure name 412 may be related to a plurality of functions. Therefore, the related function 415 includes a plurality of columns of related functions 1 to m (1 ≦ m) so that a plurality of related functions can be recorded.

  The occurrence stage 416 indicates at which development stage of the project the fault indicated by the fault name 412 occurred. The discovery stage 417 indicates in which development stage of the project the fault indicated by the fault name 412 was found.

  The other information 418 is information related to the fault indicated by the fault name 412 and is not included in the generation function 414, the related function 415, the generation stage 416, and the discovery stage 417. The other information 418 may also have a plurality of pieces of information for the failure indicated by the failure name 412. For this reason, the other information 418 includes a plurality of columns of other information 1 to other information n (1 ≦ n) so that a plurality of other information can be recorded. The other information 418 is optional and is not an essential item in the present invention. The configuration of the failure information database 41 shown in FIG. 4 is an example showing at least the information that the failure information database 41 should have except for the other information 418. The failure information database 41 shown in FIG. Any information having equivalent or more information may be used.

  The format / configuration of the functional specification 22, design stage information 23, and test information 24 has been determined, and a computer is used if the contents are described according to the format / configuration or summarized in a table format. Analysis becomes easier. Therefore, the functional specification 22, the design stage information 23, and the test information 24 are preferably configured as described above. However, in the present invention, any data structure or format may be used as long as it includes information that can be reliably searched without ambiguity in the sentences, keywords, and charts used.

  FIG. 5 is a flowchart showing a procedure of processing operations in the design review support apparatus 1 for software development shown in FIG. The processing operation of the design review support apparatus 1 in this embodiment will be described with reference to FIG.

  First, the checklist creation unit 13 extracts a keyword indicating the design stage to be reviewed for the project being developed from the design stage information 23 (step S1). The design stage information 23 is specified and the instruction to the checklist creation unit 13 is executed by the user of the design review support device 1 using the input / output device 19. In the following description, among the designation of information and control commands, information that the design review support apparatus 1 needs to input and operation designation that cannot be determined by the design review support apparatus 1 are determined by the user of the design review support apparatus 1. It is assumed that it is executed using the input / output device 19.

  Next, the check list creation unit 13 matches the keyword extracted in step S1 with the related design stage information 215 in the standard check list database 21 or includes a check item 213 having related design stage information 215 including the keyword. Extracted from the standard checklist database 21 (step S2).

  Next, the check list creation unit 13 searches the function specification 22, the design stage information 23, and the test information 24 using the related function 214 and other conditions 216 of the check item 213 currently being processed as keywords. S3). Then, the check list creation unit 13 determines whether or not the keyword is included (step S4). Here, the functional specification 22 to be searched, the design stage information 23, and the test information 24 are designated by the user of the design review support apparatus 1.

  If the predetermined keyword is not included in the function specification 22, design stage information 23, and test information 24 in the search in step S3 (No in step S4), the process jumps to step S6, and the check list creation unit 13 Is checked (step S6). If the next check item exists (Yes at step S6), the process returns to step 3, and the processing after step S3 is performed with the next check item 213 as a processing target. If the next check item does not exist (No at step S6), the process ends.

  On the other hand, in the search in step S3, when a predetermined keyword is included in the functional specification 22, the design stage information 23, and the test information 24 (Yes in step S4), the checklist creation unit 13 is a processing target. The check item 213 is output to the check list database 25 as a check item necessary for the review, and the check list database 25 additionally sets the check item 213 in the check list 250 (step S5).

  At this time, information on the serial number 212 and the check item 213 in the standard check list database 21 is set in the standard check list serial number 251 and the check item 253 in the check list 250, respectively. A unique number in the check list database 25 is assigned to the check list serial number of the check list 250. The confirmation date 254 is initialized to a clear (unchecked) state. Further, in the other information 255, information in the standard checklist database 21 is set as necessary. The user of the design review support apparatus 1 specifies the check list database 25 that is the output destination of the check item 213 that is the processing target.

  Next, the check list creation unit 13 confirms whether the next check item exists (step S6). If the next check item exists (Yes at step S6), the process returns to step 3, and the processing after step S3 is performed with the next check item 213 as a processing target. If the next check item does not exist (No at step S6), the process ends.

  As described above, in this embodiment, the check items used for reviewing the software to be developed using the functional specification 22, the design stage information 23, the test information 24, and the standard checklist database 21 are as follows. It can be generated automatically. The generated check items are automatically stored in the database as a check list. As a result, in this embodiment, it is possible to automatically generate and maintain check items and check lists, and to efficiently perform software design reviews without bothering humans. To do.

  In addition, since the check items of the software to be developed are generated using the functional specification 22, the design stage information 23, the test information 24, and the standard checklist database 21, each time new software is developed, There is no need to regenerate the checklist from the beginning, and the labor and time for generating the checklist can be greatly reduced. Therefore, a check list can be created efficiently.

  Since the generation and maintenance of check items and check lists can be performed automatically, the generation and maintenance of check items and check lists can be performed easily and efficiently even when the scale of software to be developed increases. It is possible to objectively and accurately reflect information such as test information and fault information in the checklist. As a result, the development of the target software can be facilitated and can be deployed and operated at an early stage.

  Therefore, in the design review support apparatus 1, a review support apparatus that can easily create and maintain a checklist and that can perform an efficient design review is realized.

Embodiment 2. FIG.
In the second embodiment, another embodiment of the present invention will be described. FIG. 6 is a flowchart showing a procedure of processing operations in the present embodiment in the design review support apparatus 1 for software development shown in FIG. The processing operation of the design review support apparatus 1 in this embodiment will be described with reference to FIG.

  First, the failure analysis unit 12 sets each check item in the standard checklist database 21, that is, a check item 213, a related function 214, related design stage information 215, and other conditions 216 for each piece of failure information in the failure information database 41. Searching and collating (step S101), it is determined whether or not the failure information has already been registered in each check item (step S102).

  Here, when failure information is registered in each check item of the standard checklist database 21, that is, the check item 213, the related function 214, the related design stage information 215, and the other conditions 216 (Yes in Step S102), Step S104 The failure analysis unit 12 confirms whether or not the next failure information exists, and determines whether or not to execute a loop on the failure information in the failure information database 41. If the next failure information exists (Yes at Step S104), the process returns to Step S101, and the processing after Step S101 is performed with the next failure information as a processing target. If the next failure information does not exist (No at step S104), the process ends.

  In addition, when failure information is not registered in each check item of the standard checklist database 21, that is, the check item 213, the related function 214, the related design stage information 215, and the other conditions 216 (No in step S102), it is registered. No failure information is registered in the standard checklist database 21 (step S103). At this time, the serial number 411 of the fault information database 41, the fault contents and the corresponding contents in the fault name 412, the generation function 414 and the related function 415, the generation stage 416, the discovery stage 417, and other information 418 are standardized. The fault information serial number 211, the check item 213, the related function 214, the related design stage information 215, and the other conditions 216 of the check list database 21 are set. Then, a unique number in the standard checklist database 21 is assigned to the serial number 212 of the standard checklist database 21.

  As described above, in the present embodiment, the failure information stored in the failure information database 41 is collated with each check item stored in the standard checklist database 21 and is not registered in the standard checklist database 21. If there is fault information, it is automatically registered. Thereby, the check item used in order to review the software to be developed can be automatically generated. The generated check items are automatically stored in the database as a check list. As described above, in this embodiment, it is possible to automatically generate and maintain check items and check lists, and to efficiently perform software design reviews without bothering humans. It is.

  In addition, new software is developed to generate check items for the software to be developed using the failure information stored in the failure information database 41 and the check items stored in the standard checklist database 21. There is no need to generate the checklist for the software from the beginning each time, and the labor and time for generating the checklist can be greatly reduced. Therefore, a check list can be created efficiently.

  Since the generation and maintenance of check items and check lists can be performed automatically, the generation and maintenance of check items and check lists can be performed easily and efficiently even when the scale of software to be developed increases. It is possible to reflect the failure information objectively and accurately in the check list. As a result, the development of the target software can be facilitated and can be deployed and operated at an early stage.

  Therefore, in the present embodiment, a review support apparatus that can easily create and maintain a checklist and can perform an efficient design review is realized.

Embodiment 3 FIG.
In the third embodiment, a modification of the second embodiment will be described. In the above-described second embodiment, the case where all the standard checklist database 21 is automatically created has been described. However, in the present invention, part of the creation of the standard checklist database 21 can also be performed by user input. It is. In this case, the user of the review support device can input a desired check item and its related information using the input / output device 19 and store it in the standard checklist database 21.

  In this way, by inputting a desired check item and its related information by user input and storing it in the standard check list database 21, for example, a general standard check item or a check automatically extracted as described above. It becomes possible to register and check design know-how and special creations that the software developer does not appear as check items. This makes it possible to list check items with a greater degree of freedom and to support the development of higher quality software.

Embodiment 4 FIG.
In the fourth embodiment, another embodiment of the present invention will be described. The status of an ongoing project changes dynamically. Accordingly, it is not sufficient to create the contents of the standard checklist 210 and the checklist 250 from information obtained from past projects, and it is preferable to follow the dynamic changes of the projects. For this reason, the processing operation described in the first and second embodiments with reference to FIGS. 5 and 6 is performed in accordance with the test information 24 created in the project currently being developed and the failure information database 41 accumulated. It is preferable to replace the failure information.

  For example, the check list creation unit 13 in the first embodiment described above is used as the check item addition unit 14, and the functional specification 22, design stage information 23, and test information 24 that are input to the check list creation unit 13 are currently under development. As described in the first embodiment, the check list database 25 and the standard check list database 21 are used as the test information 24 of the project and the check list database 25 output from the check list creation unit 13 (FIG. 5). Corresponding to). Note that the description of the processing refers to the above-described first embodiment, and detailed description thereof is omitted individually.

  In addition, the failure analysis unit 12 in the second embodiment described above is used as the check item addition unit 14, the failure information database 41 input to the failure analysis unit 12 is used as the failure information database 41 of the project currently being developed, The standard checklist database 21 output from the failure analysis unit 12 is used as the standard checklist database 21 and the checklist database 25, and the processing described in the second embodiment (corresponding to FIG. 6) is performed. For the description of the processing, refer to the above-described second embodiment, and detailed description thereof is omitted individually.

  As described above, the processing in the first embodiment and the second embodiment described above is performed by replacing the failure information in the failure information database 41 and the test information 24 created in the project currently being developed. Thus, it is possible to generate a check item that follows a dynamic change of a project under development and automatically create a check list 250 based on newer information. Thereby, it is possible to automatically create a check list 250 that is more realistic.

Embodiment 5 FIG.
The fifth embodiment is another embodiment of the present invention, and will be described as an embodiment for automatically checking the contents of a check list. 7 and 8 are flowcharts showing the procedure of the processing operation in the present embodiment in the design review support apparatus 1 for software development shown in FIG. The processing operation of the design review support apparatus 1 according to the present embodiment will be described with reference to FIGS.

  First, a mode of automatically checking the contents of the check list using the check list database 25 and the failure information database 41 will be described with reference to FIG. First, the check list check unit 15 searches the check items in the check list 250 stored in the check list database 25, and extracts the latest confirmation date / time from the recorded confirmation dates / times 254 (step S201).

  Next, the check list check unit 15 searches the failure information stored in the failure information database 41 and records the occurrence date / response date 413 newer than the latest confirmation date extracted in step S201. Fault information is extracted (step S202).

  Next, the check list check unit 15 extracts check items for which the confirmation date 254 is undetermined from the check items in the check list 250, and further adds the failure information currently being processed from the extracted check items. Related items are extracted (step S203). This extraction is performed by collating the data items of the fault information shown in FIG. 4 as the processing target of the fault information database 41 with the information of the check items 253 and other information 255 of the check list 250.

  Next, the check list check unit 15 sets the corresponding date and time of the failure information as the confirmation date and time of the extracted check item (step S204). Then, the check list check unit 15 checks whether or not other extracted failure information exists (step S205). If there is other extracted failure information (Yes at Step S205), the process returns to Step S203, and the processes after Step S203 are performed. On the other hand, when there is no other extracted failure information (No at Step S205), the process is terminated.

  Next, a mode of automatically checking the contents of the check list using the check list 250 and the test information 24 will be described. First, the check list check unit 15 searches the check items in the check list 250 stored in the check list database 25, and extracts the latest confirmation date / time from the recorded confirmation dates / times 254 (step S301).

  Next, the checklist check unit 15 searches the test information 24, and extracts test information in which a test confirmation date and time that is newer than the latest confirmation date and time extracted in step S301 is extracted (step S302).

  Next, the check list check unit 15 extracts check items for which the test confirmation date is undetermined from the check items in the check list 250, and further converts the extracted check items into test information currently being processed. Related items are extracted (step S303).

  Next, the check list check unit 15 sets the test confirmation date and time as the confirmation date and time of the extracted check item (step S304). At this time, if the confirmation date and time 254 of the check item already extracted is set, the newer one of the corresponding date and time obtained from the test information 24 and the already set registration date and time is set as the confirmation date and time 254.

  Then, the check list check unit 15 checks whether or not other extracted test information exists (step S305). If there is other extracted test information (Yes at Step S305), the process returns to Step S303, and the processes after Step S303 are performed. On the other hand, if there is no other extracted test information (No at step S305), the process is terminated.

  As described above, in the present embodiment, the contents of the checklist can be automatically checked using the checklist database 25 and the failure information database 41. In the present embodiment, the contents of the check list can be automatically checked using the check list 250 and the test information 24. Thereby, it is possible to greatly reduce the labor and time for checking the contents of the check list. And even when the scale of the software to be developed becomes large, the contents of the checklist can be checked easily and efficiently, facilitating the development of the target software and early deployment and operation. Is possible.

Embodiment 6 FIG.
In the sixth embodiment, a mode for erasing check items stored in the check list database 21 according to another embodiment of the present invention will be described. FIG. 9 is a flowchart showing the procedure of the processing operation in the present embodiment in the design review support apparatus 1 for software development shown in FIG. The processing operation of the design review support apparatus 1 in this embodiment will be described with reference to FIG.

  First, the checklist result totaling diagnosis unit 16 searches for check items in the check list 250, the confirmation date 254 remains undecided, and the other information 255 does not need to be checked in the current project (not required as a check item). (B) Extract check items recorded as check items (step S401).

  Next, the checklist result totaling diagnosis unit 16 searches the standard checklist database 21 and adds check-unnecessary flag information to check items that are processing targets, that is, check items that match the check items extracted in step S401. Is added (step S402).

  Next, the check list result aggregation diagnosis unit 16 confirms whether or not there is a check item to be processed next (step S403). If there is a check item that is the next processing target (Yes at Step S403), the process returns to Step S402, and the processes after Step S402 are performed.

  On the other hand, if there is no check item to be processed next (No in step S403), the checklist result totaling diagnosis unit 16 has the unnecessary flag information set in the standard checklist database 21 via the control unit 11. The user of the design review support apparatus 1 confirms whether to delete the check item (step S404).

  Here, the user of the design review support apparatus 1 gives an instruction to delete each check item requested to be confirmed by the design review support apparatus 1 from the standard checklist database 21 or leave it as it is or modify it. An input / output device 19 is used to input the checklist result aggregation diagnosis unit 16 to the design review support device 1. Then, the checklist result totaling diagnosis unit 16 deletes or saves the check item according to the instruction (step S405).

  As described above, in the present embodiment, among the check items stored in the check list database 21, check items that are not required to be checked in the project (unnecessary as check items) can be automatically extracted. it can. As a result, the user can automatically organize and maintain the check items in the check list database 25 without performing complicated operations only by determining whether to delete or save the check items. Therefore, even when the scale of the software to be developed becomes large, check items and check lists can be maintained and managed easily and efficiently, and information such as test information and fault information can be objectively and accurately determined. It can be reflected in the checklist. As a result, the development of the target software can be facilitated and can be deployed and operated at an early stage.

  As described above, the review support apparatus according to the present invention is useful when an efficient design review is realized by easily creating and maintaining a checklist, and in particular, the scale of software to be developed is large. Suitable for cases.

It is a block diagram which shows an example of a structure of the design review assistance apparatus concerning this invention. It is a figure which shows the data structure of the check list which the check list preparation part of the design review assistance apparatus shown in FIG. 1 produces. It is a figure which shows the data structure of the failure information database which the failure analysis part of the design review assistance apparatus shown in FIG. 1 refers. It is a figure which shows the data structure of the standard checklist database which the checklist preparation part of the design review assistance apparatus shown in FIG. 1 refers. It is a flowchart which shows the operation | movement in Embodiment 1 of the design review assistance apparatus shown in FIG. It is a flowchart which shows the operation | movement in Embodiment 2 of the design review assistance apparatus shown in FIG. It is a flowchart which shows the operation | movement in Embodiment 5 of the design review assistance apparatus shown in FIG. It is a flowchart which shows the operation | movement in Embodiment 5 of the design review assistance apparatus shown in FIG. It is a flowchart which shows the operation | movement in Embodiment 6 of the design review assistance apparatus shown in FIG.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Design review support apparatus 2 Failure management apparatus 11 Control part 12 Failure analysis part 13 Check list creation part 14 Check item addition part 15 Check list check part 16 Check list result totaling diagnosis part 19 Input / output device 21 Standard check list database 22 Functional specification 23 Design Stage Information 24 Test Information 25 Check List Database 31 Fault Management Control Unit 41 Fault Information Database 210 Standard Check List 211 Fault Information Serial Number 212 Serial Number 213 Check Item 214 Related Function 215 Related Design Stage Information 216 Other Information 250 Check List 251 Standard checklist serial number 252 Checklist serial number 253 Check item 254 Confirmation date / time 255 Other information 411 Serial number 412 Fault name 413 Occurrence date / time 414 Generation function 415 Related function 416 Generation stage 417 Discovery stage 418 Other information

Claims (9)

Standard check item storage means for storing a plurality of standard check items used for software review,
Input means for inputting functional specification information of the development target software as input information, design stage information obtained at the design stage of the development target software, and test information used for testing the development target software,
Check item extraction means for extracting check items necessary for review of the development target software by collating the standard check items with the input information;
Check item storage means for storing the check items extracted in the check item extraction means;
A review support apparatus comprising:   The check item extraction unit extracts a keyword indicating a design stage to be reviewed from the design stage information, compares the keyword with the standard check item, extracts the standard check item including the keyword, and then extracts the standard check item. The review support apparatus according to claim 1, wherein a check item necessary for a review of development target software is extracted by collating a standard check item with the input information. The failure information of the failure that occurred during the development of the developed software and the development target software is input and the failure information is compared with the standard check item. If the failure information is not included in the standard check item, the failure information The review support apparatus according to claim 1, further comprising a failure information analysis unit that automatically registers information in the standard check item. The review support apparatus according to claim 3, wherein a check item necessary for review of the development target software can be input by the input unit. The failure information analysis means collates the failure information with the standard check item using the failure information of the latest failure that occurred during the development of the development target software as input information, and stores the latest failure in the standard check item. 4. The review support apparatus according to claim 3, wherein when the failure information is not included, the failure information is automatically added and registered in the standard check item. Using the latest test information for the review of the development target software as input information, the input information and the standard check items are collated to extract additional check items necessary for the review of the development target software, and the additional check items The review support apparatus according to claim 1, further comprising: a check item adding unit that automatically registers a check item in the standard check item. Extracting the latest confirmation date and time of the check item stored in the check item storage means, extracting failure information for which failure handling has been performed after the latest confirmation date and time from the failure information, and from the latest confirmation date and time A check means is provided for automatically performing a check corresponding to a failure on a check item that has not been confirmed, among the check items related to failure information for which a failure has been handled later. Item 4. The review support device according to any one of Items 1 to 3. Extract the latest confirmation date and time of the check item stored in the check item storage means, extract from the test information the test information that was tested after the latest confirmation date and time, more than the latest confirmation date and time 2. A check means for automatically performing a check corresponding to a check item for a check item that has not been checked for confirmation among the check items related to test information that has been tested later. The review assistance apparatus as described in any one of -3. The review support apparatus according to claim 1, wherein the check item stored in the check item storage unit is erasable.

Images