JP3290778B2 - Trouble analysis support device - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a trouble analysis support apparatus for compiling and analyzing the contents of troubles occurring in software development, and for feeding back the analysis result to a software development site to improve software quality. .

[0002]

2. Description of the Related Art In the development of software, it is important to build quality in each process, and various methods for improving quality are considered in each process. As a result, it is possible to find an error at an early stage, it is possible to reduce the number of backward operations, and to reduce the number of development steps.

[0003] As one of the techniques for realizing high quality, use of a checklist is generally adopted. For example, a checklist is used for each process such as a requirement analysis process, a design process, and a program creation process. The checklist is used to list points to be noted as items and call them attention by checking them. For example, if the checklist used in the design process of the program related to transmission / reception includes a check item such as "Is the data destination correct?" Or "is it designed to send everything to the destination?"

Since the designer is a human, he checks the specifications,
Even if you intend to design according to specifications, you may make a mistake without realizing it. By calling attention to such an inadvertent mistake using a checklist, high-quality software can be produced for each process. Also,
Use of checklists not only prevents accidental mistakes,
For developers with little software experience, for example, check the check items such as "Is the data display left-justified when the data digit is shorter than the set value?" It is also useful for acquiring the knowledge that the design should be made in consideration of the time when it was taken or too long, and that this project is a standard form of left justification.

If a checklist is used, even if the design target is complicated and large-scale, attention to check items can reduce oversight of small errors and improve quality. In order to use checklists efficiently, it is important to enhance the quality of the checklist itself. However, checklists that have been created have not been reviewed much.

Various methods are used in addition to the method of improving quality using a checklist. For example,
There is also a method in which the structure of a program is measured on a scale such as “the number of steps” or “the number of conditional branches”, and for a program having a complicated structure, a method such as reviewing the function or dividing the program is performed.

[0007] However, even if software is developed using the above-described method, troubles often occur at the test stage and thereafter. When these troubles are found, the software is modified.

When such corrections are made, it is possible to obtain information such as "what causes many occurrences" and "what kind of trouble occurred frequently". In many cases, only know-how is accumulated as the know-how of developers and correctors. It is rarely accumulated not only as personal know-how but also as common know-how for the next project. Here, know-how refers to general software development, such as "what kind of points can be developed to create high-quality software that does not cause problems" and "where is the cause of problems when problems occur?" , Field-dependent, project-dependent.

Therefore, in order to efficiently develop high-quality software, it is necessary to analyze the trouble information in detail and feed back the analysis result to the development site.
Trouble analysis can be used as follows.

(1) It is an important reference for improving the checklist. Rather than always using the same checklist, it is desirable to change the contents of the checklist in response to changes in the characteristics of the project and the capabilities of the developers,
By adding items that easily lead to troubles to the checklist, the checklist can be easily improved.

(2) It is an important reference for the test item creation work. In considering the test items, if the cause of the trouble in the previous development is grasped, the trouble can be found efficiently at the time of the test, for example, by increasing the number of tests where the trouble is likely to occur.

(3) When a trouble occurs in the next development, it becomes an important clue for finding out where the cause exists. When a trouble occurs, if a similar trouble has occurred before, it can be imagined that the cause is similar, and the cause of the trouble can be identified quickly.

As described above, it is very important to analyze a trouble in order to improve software quality. However, it was difficult to analyze the trouble and utilize the results for the following reasons.

(1) It is recognized that the analysis of trouble is important. However, the analysis is troublesome and is often not performed. There are mainly four specific reasons why trouble analysis is difficult.

(A) The causes of the troubles described in the trouble sheet vary from those in which only one word is written to those in which it is written in very detail. Also, different expressions are used for different people even for the same cause.

(B) Since the trouble sheet is not digitized and is often in the form of paper, counting and searching are performed manually. (c) In order to visualize the tabulated results, the data must be converted into a form that can be displayed in a graph.

(D) The analysis procedure (what data should be analyzed and how to analyze it) is not clear. (2) There is no point in analyzing the trouble if the results cannot be used effectively. However, as described in (1), since the trouble sheet is not digitized and often remains on paper, the search is also a manual operation. Therefore, for example, when examining the causes of reliability-related troubles (troubles that have caused the system to stop functioning at all, such as a system down), all the trouble sheets should be checked. In addition, it is necessary to prepare in advance a relation between the phenomenon and the cause of such a trouble.

(3) As mentioned earlier, the analysis result of the trouble is an important reference for improving the checklist. However, if it is completely independent, the checklist will not be improved. It tends to be. As described above, there is no established way to immediately reflect the analysis result of the trouble in the checklist.

As described above, in the conventional software development site, since a trouble analysis method has not been established, it is not only difficult to analyze the trouble, but also trouble information is fed back to the development site and actively used. It was difficult.

[0020]

SUMMARY OF THE INVENTION Accordingly, an object of the present invention is to provide a trouble analysis support apparatus which can facilitate analysis of troubles found during and after software development and can contribute to utilization of the analysis results. And

[0021]

To achieve the above object, a trouble analysis support apparatus according to the present invention provides a trouble data input device for inputting trouble data including the contents of a trouble in accordance with a predetermined classification format. Means,
Trouble data storage means for storing the trouble data input by this means, trouble data search means for searching for trouble data falling within a specified condition from among the trouble data stored in this means,
Trouble search result display means for displaying search results by this means, trouble analysis means for analyzing troubles in a specified range of the trouble data, and display for visually displaying the analysis results by this means Means.

It is more effective to provide a checklist updating means for reflecting the result of analysis by the trouble analyzing means on a checklist used during software development.

[0023]

By simply inputting trouble data including the contents of a trouble in accordance with a predetermined classification mode, it is possible to automatically perform data totalization, search, display, and the like. In other words, it is possible to replace the expression of the cause of the trouble that a human has been thinking about each time with a simple operation of merely giving an option. Also, by providing a function for simultaneously managing checklists, it is possible to easily improve checklists.

[0024]

Embodiments will be described below with reference to the drawings. FIG. 1 shows a schematic configuration of a trouble analysis support device according to one embodiment of the present invention.

This trouble analysis support apparatus is roughly divided into a trouble data input / storage section 1, a trouble data search / display section 2, a trouble analysis / result display section 3, a check list update / storage section 4, And a database 5.

The trouble data input / storage unit 1 is a part for extracting necessary information from a trouble sheet S describing troubles found during and after the development of software and storing the extracted information in the database 5. Trouble data input unit 11 for inputting data
And a trouble data storage unit 12 for storing the input data in the database 5.

The trouble data search / display unit 2 stores, for example, only troubles of a specific cause or troubles handled by a specific person with respect to a trouble of a certain project so that the trouble can be observed or analyzed. The system includes a trouble data search unit 21 for searching for troubles using a search key and a trouble data display unit 22 for displaying searched trouble data.

The trouble analysis / result display section 3 extracts trouble information from the database 5 (if necessary, uses the trouble data search section 21 in the trouble data search / display section 2 to analyze and Trouble data to be analyzed), a trouble analysis unit 31 for analyzing the trouble, an analysis result storage unit 32 for storing the analysis result in the database 5, and an analysis result display unit 33 for displaying the analysis result. ing.

As shown in FIG. 2, a trouble analysis unit 31 normalizes the number of trouble occurrences on a development scale and analyzes the trouble occurrence density analysis unit 31-1. The analysis is performed by classifying according to the cause-specific analysis unit 31-2 and the quality characteristics (functionality, reliability, usability, efficiency, maintainability, portability, and quality characteristics to be satisfied by software) affected by the trouble. An analysis unit 31-3 according to quality characteristics to be performed, and an analysis unit 31-4 according to the processing contents which classifies the target software processing into several parts and analyzes each processing content, and classification corresponding to the degree of influence of the trouble And a trouble influence degree analyzing section 31-5.

The checklist updating / storing unit 4 reads a checklist used in software development from the checklist file 53 of the database 5 and simultaneously reads a trouble analysis result used for updating the checklist from the trouble analysis result file 52 of the database 5. (If the analysis result to be used is not stored, a trouble analysis is performed and the result is used). A checklist updating unit 41 that automatically reflects the result of the trouble analysis on the contents of the checklist is provided. The checklist storage unit 42 is stored in the database 5 again.

The database 5 includes a trouble data file 51 for storing trouble data, a trouble analysis result file 52 for storing results of trouble analysis, and a checklist file 5 for storing checklists.
3 files.

Next, the processing flow of the trouble data input / storage unit 1, trouble data search / display unit 2, trouble analysis / result display unit 3, and check list update / storage unit 4 will be described with reference to flowcharts. .

FIG. 3 shows a processing flow of the trouble data input / storage section 1. First, the user inputs the project name, version name, development scale, etc. of the trouble data to be entered (step 101). The development scale is
Fill in “Reuse”, “Modify”, and “New” separately. Here, "reuse" is a module that uses the previous version of the module without any changes.
“Modified” is a module obtained by modifying the module of the previous version, and “New” means a module newly developed in this version. (When the development scale is represented by the number of screens, Changes depending on how the development scale is represented.

Next, necessary data is selected and input while referring to the trouble sheet S (step 102). The trouble sheet S to be referred to may be digitized or a paper trouble sheet. Usually, the trouble sheet is often managed by paper, so that both can be used.

Next, a selection is made as to whether or not the input data is to be stored in the database 5 (step 103). When the input data is to be stored, the file name is specified and the data is stored (step 104).

FIG. 4 shows the flow of processing of the trouble data search / display unit 2. First, a project name and a version name are input (step 201). Next, a key to be searched is specified based on the cause of the trouble, the degree of trouble, and the like (step 202), and the corresponding trouble data is read from the trouble data file 51 (step 203).
A selection is made as to whether or not to display the searched trouble data (step 204), and when the display is selected, the display is performed (step 205). The reason for selecting whether to display is not to analyze the entire project trouble, but to analyze only the trouble within a certain period or only the trouble of a specific cause in the trouble analysis described below. This is because the search result may be used as preprocessing for trouble analysis instead of displaying and viewing the search result.

FIGS. 5 and 6 show the processing flow of the trouble analysis / result display unit 3. First, a project name and a version name of a trouble to be analyzed are specified (step 301). If you omit the version name, all versions of the project will be included. With respect to the trouble of the specified project, a selection is made as to whether to perform an analysis using all the data or to perform an analysis using partially selected data (for example, only those of a specific cause) (step 302). When analyzing with partial data, a search is performed in advance using the trouble data search and display unit 2 described above, and it is checked whether or not data limitation (partial data extraction) has been performed. (Step 303). If the data is not limited (partial data extraction), trouble data is searched to extract necessary data (step 304).
). Database 5 for analysis with all data
When the analysis is performed from the trouble data file 51 or partial data, the search result data is read into the memory (step 305).

Thus, the trouble data to be analyzed has been prepared. Next, it is selected whether or not trouble analysis for the data is the first time (step 306).
) In the first case, specify the analysis method (Step 3)
07) Perform analysis (step 308) and select whether to save the analysis result (step 309). When save is selected, the analysis results are stored in the trouble analysis result file 5
2 (step 310). Finally, it is selected whether or not to end the analysis (step 311). If it is to be ended, the trouble analysis is ended. If not, the flow returns to the selection of the analysis method (step 307).

If it is determined in step 306 that the analysis of the data is not the first time, a selection is made as to whether or not to perform a re-analysis (step 312). If reanalysis is selected here, an analysis method is selected and analysis is performed as in the first analysis (step 307). If not reanalyzed, a selection is made as to whether or not to display past analysis results (step 313). If so, the corresponding analysis results are read from the trouble analysis result file 52 (step 314) and displayed on the screen. (Step 315
).

FIG. 7 shows the flow of processing of the checklist updating / saving unit 4. First, a checklist to be changed is selected and read from the checklist file 53 (step 401). At the same time, it is checked whether an analysis result to be used for updating the check list exists in the trouble analysis result file 52 (step 402), and if so, the analysis result is read (step 403). If the necessary analysis result is not stored, a trouble analysis is performed (step 404), and the result is obtained.

Next, since the cause of the trouble is clarified from the result of the trouble analysis, the check list is automatically updated so that the trouble can be prevented by checking them in advance (step 405). . Finally, it is selected whether to save the updated checklist (step 406), and when it is designated to save, it is saved in the checklist file 53 (step 407).
).

Next, the embodiment will be described in more detail by taking a trouble analysis of a business processing program as an example. This embodiment is an example realized on a multi-window computer.
As shown in FIG. 8, it is started from the trouble analysis menu displayed on the screen.

The process to be executed is selected from the menus of “trouble data input / save”, “trouble data search / display”, “trouble analysis / display”, and “checklist update / save” displayed on the screen with a mouse. Click to select.

Assuming that "trouble data input / save" is selected, a window shown in FIG. 9 is activated.
Therefore, the user inputs the project name, version name, input person name (for managing trouble data) and development scale of the trouble data to be inputted. After confirming whether there is any error in the input items and clicking the confirm button, a trouble data input window shown in FIG. 10 is opened. Enter the trouble data here. The project name, version name, and input person name are the first input, and the input date is automatically entered by the date managed by the computer. Other items are input while referring to the trouble sheet S.

First, the trouble number, the date of finding the trouble, the person who found the trouble, the date of dealing with the trouble (correction was made so as not to cause the trouble), and the person who responded to the trouble are entered. Next, enter the cause. Here, the causes of the trouble are roughly classified into three: "basic software", "applied software", and "hardware". The basic software means an OS (Operating System) or the like. The business processing program targeted by this embodiment is applied software, and most trouble causes are in "applied software". However, very rarely, there is a cause in the basic software, for example, the interrupt processing of the OS does not work well, or a problem in the hardware, such as that the intended performance cannot be obtained due to insufficient machine performance. In some cases, such a classification is used.

When a cause is selected from these three and clicked, a window for prompting the user to input a more detailed cause is opened for each of them. FIG. 11 shows an example in which “applied software” is selected. As the detailed cause, items created with reference to past cases are given, and are selected from the items. Therefore, the cause column of the trouble sheet S may be read, and one or more applicable causes may be selected. If the cause does not apply, select Other and describe the details. However, the other details are always described in the form of “There was.” (The description method is restricted in order to automatically reflect it in the checklist.) Note that each cause has a comment field, which should be noted (for example,
At the time of the file overflow, if there is any information that is useful for the next development, such as how much the capacity of the A file has been set, but more than one is needed, enter it.

After the cause input is completed, the user clicks the cause input end button, and returns to FIG. 10 to enter the location of occurrence. This is to categorize the processing of the target software into several types and to clarify which processing caused the trouble. In the present embodiment, since the business processing program is targeted, it is classified into “screen-related processing”, “communication-related processing”, “form-related processing”, “file-related processing”, and “other processing”. One or a plurality of processes related to the trouble are selected and clicked from these five.

Next, whether the module having the trouble is “reuse”, “remodel”, or “new” is entered. Here, “reuse” is a module that uses the previous version of the module without any change, and “modification” is a module obtained by modifying the previous version of the module, and “new”. Means a completely new module developed in this version.

Next, the affected quality characteristics are entered. There are the following six quality characteristics. (1) Functionality: Satisfies the functions described in the specifications. (2) Reliability: software is continuously executed under certain conditions.

(3) Usability: easy for the user to use. (4) Efficiency: The efficiency of software execution under certain conditions. (5) Maintainability: Ease of software maintenance.

(6) Portability: easy portability to different environments. Click on one or more of the quality characteristics that are no longer satisfied due to the trouble.

Next, the degree of influence of the trouble is entered. If the trouble caused the system to stop functioning at all, such as a system failure, "Large", if it partially stopped functioning, "Medium", message characters were garbled, etc. If there is no problem, set to "Small", and if it seems to be trouble, but meet the specifications, set to "No".

In addition, the user inputs necessary trouble data according to the contents to be analyzed. Click the Save button to save the entered trouble data. Also,
If you want to move to another trouble data number sheet during input, you can move to the previous page, next page, or goto button. Thus, trouble data is sequentially input.

When "trouble data search / display" is selected from the start menu shown in FIG. 8, a search window shown in FIG. 12 is started. Here, a project name and a version name are specified, and trouble data relating to the project name and the version name are searched for those satisfying a certain condition. To specify a condition, a conditional statement is expressed by connecting it with a connector, and is entered in the search condition entry column. Conditions that can be set include a trouble data number, a trouble finding date, and the like, which are already prepared and combined.

For example, if the trouble data number is 1 to 2
In the case of searching for items having a trouble influence degree between 0 and 0, the trouble data number of the condition name A is designated as 1 to 20 first. Next, move the cursor to the position where you want to enter the condition entry column in the search condition entry column,
Then, the user clicks the condition name A. Then, the content of the condition name A is copied to the condition entry column. Similarly, move the cursor to the condition entry field and select A from the connector selection.
Clicking on ND will copy it to the location where the cursor is. Next, the degree of trouble influence of the condition name G is designated, and similarly copied to the search condition entry column. If the search condition is complicated, it is expressed using parentheses. When setting the condition relating to the cause of the trouble, if any of the basic software, the application software, and the hardware is selected in the condition item of the cause of the trouble, a condition setting screen for the detailed cause corresponding thereto is started as shown in FIG. FIG. 13 is an example of application software), so the setting is made on this screen. When the cause of a trouble is set as a condition and no detailed cause is set, a large classification of the cause (basic software, application software, and hardware) is used as a search condition (for example, all troubles caused by application software). Since the search condition entry column is an editor, it can be entered directly, but the way of writing is restricted. Click the search start button when the search conditions have been described.

When the search is started, a message "searching" is displayed in a message column, and when the search is completed, a message "search complete" is displayed. Click the display button to display the search results. Then, the windows shown in FIG. 14 and FIG. 15 are launched in one set, and the searched trouble data can be viewed. FIG. 15 shows a case in which the cause is caused by the application software. In the case where the cause is caused by the basic software or the hardware, detailed causes corresponding to the respective cases are displayed.

When "trouble analysis / display" is selected in the start menu shown in FIG. 8, a window shown in FIG. 16 is started, and an analysis to be executed is selected.

First, a project name and a version name are specified. Next, the user selects and clicks "Read all data" or "Read search data", which is a selection of which of the trouble data is to be analyzed.

When "read all data" is selected, the entire trouble data of the specified version of the project is to be analyzed. If you select "Search data loading", data that meets a certain condition (for example, only a specific cause or the degree of Only the objects). If "read search data" is selected and the search has not been performed yet, a message box is displayed so that the search is performed first and then the analysis is started.

When performing an analysis, the user clicks an analysis button of an analysis item to be performed. When the “trouble occurrence density analysis” button is selected, a window showing the number of trouble occurrences per development scale is launched as shown in FIG. This is a good criterion when comparing with other systems or versions, because the absolute number of trouble occurrences changes depending on the development scale. Another advantage is that the approximate value of the number of troubles can be predicted when the development scale is known in the next development. The development scale used as a reference value includes 1K steps (reuse + remodeling + new),
Various things are taken, such as per module (reuse + remodeling + new), per newly developed 1K step, per screen-related process per module. The types of troubles that occur
Normalization is performed by preparing various types such as the total number of troubles, the number of screen-related processing troubles, and the number of troubles of new modules.

When the "analyze by trouble cause" analysis button is selected, as shown in FIG.
A window appears showing the number of troubles caused by application software and hardware. For each of them, a button for selecting a detailed display is prepared, and when this button is clicked, a more detailed analysis result is displayed. FIG. 19 is a display example when the detailed display of the application software is selected. As shown in this figure, a table and a bar graph in which the detailed causes are rearranged in descending order of the number of occurrences are displayed. The same detailed display can be selected for basic software and hardware.

When the “analysis by quality characteristic” analysis button is selected, a table of the number of occurrences for each quality characteristic and a bar graph are displayed as shown in FIG. Similarly, when the analysis button of “analysis by processing content” is clicked, as shown in FIG. 21, for each processing content, in this case, screen-related processing, communication-related processing, form-related processing, file-related processing, and others. The troubles related to the five processes of the above process are displayed in a table of the number of occurrences and a bar graph.

When the "analysis by trouble influence degree" analysis button is selected, a table of the number of occurrences classified by influence degree and a pie chart showing the ratio are displayed as shown in FIG.
These data are saved by clicking a save button provided for each analysis on the screen shown in FIG. When the result of the analysis once is displayed again, a display button provided for each analysis on the screen shown in FIG. 16 may be clicked.

When "Update / Save Checklist" is selected from the start menu shown in FIG. 8, a file selection screen for updating the checklist is started up as shown in FIG. Therefore, when updating
Enter the checklist file name you want to update and the trouble analysis result file name you want to use for updating. At this time,
If the specified file name does not exist in the database, a message to that effect is displayed in the message field. In this case, the necessary files are prepared beforehand (if there is no trouble analysis result, the trouble list is analyzed and then the checklist is updated).

When the specified checklist and the trouble analysis result are present, a checklist display screen before updating and a trouble analysis result display screen used for updating the checklist shown in FIG. 25 are started up as shown in FIG. . To update, click the “Update checklist” button shown in FIG. 25. To cancel, click the “Cancel update” button.

When the checklist update is selected, the checklist is automatically updated, and a screen for displaying the updated checklist is activated as shown in FIG. In the check list, all of the options of the cause given in advance in the trouble analysis result are listed as check items. In the items of the cause, "-missing" and "-error" are set, but in the check items, "-is there missing?" And "-is there an error?" Further, the cumulative number of troubles caused by the cause is stored.

When the checklist is updated, each cause of the trouble analysis result and the number of trouble occurrences used in this update are added to the accumulated value so far, and the check items in the checklist are sorted in descending order of the value. You. The sorting is performed in order to enhance the effect of the checklist by first checking the cause that has led to the trouble so far. For example, in the pre-update checklist shown in FIG. 24, the item “Is the flag setting correct?” Is at the top, whereas in the result of the trouble analysis shown in FIG. 26, the cumulative value of the number of trouble occurrences is reversed, and FIG.
In the updated checklist shown in (1), the check item “Is there any missing initialization?” Is at the top. Also, the cause described in "Others" for the cause of the trouble analysis is described as "There was", so change it to "Is there" and add it to the end of the checklist I do. Pressing the save button when the checklist has been automatically updated saves the results.

Finally, the procedure for using this embodiment will be described with reference to FIGS. 27 and 28. First, the process to be executed from among the four displayed in the startup menu: "trouble data input / save", "trouble data search / display", "trouble analysis / result display", and "checklist update / save" Select a name (Step 50
1). These processes can be performed in parallel.

When performing "trouble data input / save", necessary trouble data is input (step 502).
), Determine whether to save (step 503), and if so, save the data in a file (step 50)
Four ).

When performing "trouble data search / display", search conditions are set (step 505), and trouble data is searched (step 506). Then, it is determined whether or not to display (step 507), and if so, the search result is displayed on the screen (step 508).

When performing "trouble analysis and result display", first, trouble data to be analyzed is determined (step 509). If all the data are not used, the data is searched to confirm whether the data has been extracted (step 510). If not, the search is performed and the analysis is started. When all data is used or when analysis is performed using already searched data, an analysis method is selected (step 511), the actual analysis is performed, and the result is displayed (step 512). Next, it is determined whether or not to store the analysis result (step 513), and if so, the result is stored in a file (step 514).

When performing "update / save checklist", it is first checked whether there is a trouble analysis result to be used for updating the checklist (step 515). Start. If there is an analysis result, the checklist is updated (step 516), and it is determined whether to save the updated result (step 517), and if so, the result is saved in a file (step 518).

[0073]

As described above, according to the present invention,
The content of the trouble can be input in a unified expression, and the work can be simplified and the trouble can be automatically analyzed. In addition, since the checklist can be managed simultaneously with the result of the trouble analysis, the checklist can be efficiently improved.

[Brief description of the drawings]

FIG. 1 is a schematic configuration diagram of a trouble analysis support device according to an embodiment of the present invention.

FIG. 2 is a configuration diagram of a trouble analysis unit in the apparatus.

FIG. 3 is a diagram showing a processing flow of a trouble data input / storage unit in the apparatus.

FIG. 4 is a diagram showing a processing flow of a trouble data search / display unit in the apparatus.

FIG. 5 is a diagram showing a part of a processing flow of a trouble analysis / result display unit in the apparatus.

FIG. 6 is a view showing the rest of the processing flow of the trouble analysis / result display unit in the apparatus.

FIG. 7 is a diagram showing a processing flow of a checklist updating / saving unit in the same device.

FIG. 8 is a diagram showing an example of a startup menu screen in the device.

FIG. 9 is a diagram showing an example of an initial setting screen of a trouble data input / storage section in the same device.

FIG. 10 is a diagram showing an example of a trouble data input screen in the same device.

FIG. 11 is a diagram showing an example of a trouble detailed cause input screen in the same device.

FIG. 12 is a diagram showing an example of a trouble data search screen in the same device.

FIG. 13 is a diagram showing an example of a search condition setting screen relating to a detailed cause of a trouble in the apparatus.

FIG. 14 is a diagram showing an example of a trouble data display screen in the same device.

FIG. 15 is a diagram showing an example of a trouble detailed cause display screen in the same device.

FIG. 16 is a diagram showing an example of a trouble analysis execution screen in the same device.

FIG. 17 is a diagram showing an example of a trouble occurrence density analysis result display screen in the same device.

FIG. 18 is a diagram showing an example of a detailed result display screen of analysis by trouble cause in the apparatus.

FIG. 19 is a diagram showing an example of a detailed result display screen of analysis by trouble cause in the same device.

FIG. 20 is a diagram showing an example of a quality characteristic analysis result display screen in the apparatus.

FIG. 21 is a diagram showing an example of an analysis result display screen for each processing content in the apparatus.

FIG. 22 is a diagram showing an example of an analysis result display screen according to the degree of trouble influence in the same device.

FIG. 23 is a diagram showing an example of a file selection screen for updating a checklist in the device.

FIG. 24 is a diagram showing an example of a check list display screen before updating in the same device.

FIG. 25 is a diagram showing an example of a trouble analysis result display screen used for updating a checklist in the same device.

FIG. 26 is a diagram showing an example of a check list display screen after updating in the same device.

FIG. 27 is a diagram showing a part of a flowchart for explaining an example of use of the apparatus.

FIG. 28 is a diagram showing the rest of the flowchart for explaining an example of use of the apparatus.

[Explanation of symbols]

1 Trouble data input / storage section 2 Trouble data search / display section 3 Trouble analysis / result display section 4 Check list update / storage section 5 Database 11 Trouble data input section 12 Trouble data storage section 21 Trouble Data search unit 22 Trouble data display unit 31 Trouble analysis unit 32 Analysis result storage unit 33 Analysis result display unit 41 Checklist update unit 42 Checklist storage unit 51 Trouble data file 52 Trouble analysis result file 53 … Checklist file

────────────────────────────────────────────────── ─── Continuation of the front page (56) References JP-A-3-142636 (JP, A) JP-A-59-111553 (JP, A) Information Processing Society of Japan 27th Annual Meeting (1983) Shu, p. 613-616 (58) Field surveyed (Int.Cl. ⁷ , DB name) G06F 9/06-9/44 G06F 11/28-11/36

Claims (2)

(57) [Claims] 1. A trouble analysis support apparatus for supporting analysis of troubles discovered during and after software development.
In a trouble-data storage means for storing the trouble data input means for inputting in accordance with a predetermined classification fashion trouble data containing the contents of the trouble, the trouble data input by said trouble data input means, the trouble Trouble data search means for searching for trouble data in a specified range from trouble data stored in data storage means, trouble search result display means for displaying search results by the trouble data search means, and a plurality of analysis methods Choose one of the analysis methods
Analysis method selecting means for performing , for the trouble data in a specified range of the trouble data , trouble analysis means for analyzing the trouble according to the selected analysis method , Display means for visually displaying an analysis result by the trouble analysis means; and selection of the analysis method for the trouble data in the range.
Control the analysis process so that re-analysis is performed with different options.
A trouble analysis support device, comprising: analysis processing control means . 2. The trouble analysis support apparatus according to claim 1, further comprising a check list updating means for reflecting an analysis result by said trouble analysis means on a check list used during software development.