JP2000293411A - Device and method for fault management and recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To perform work of fault countermeasure or the like more effectively by providing a mechanism that automatically collects and analyzes information about various faults occurring on software, evaluates the results and presents them. SOLUTION: This device is provided with a data collecting part 6 which automatically collects needed information from a database 5 where information about various faults are stored, an analysis evaluation executing part 7 which analyzes the collected data and performs evaluation by comparing the analyzed results with a previously prepared evaluation reference 8 and a resulted analysis outputting part 9 which outputs the results of the analysis and evaluation to a display device, etc. Consequently, it is possible to immediately know the existence/absence of a fault by automatically executing analysis evaluation processing in an optional stage in a series of development processes even without performing work such as to analyze the fault and to make it a graph by man-power so that an appropriate countermeasures to that can be performed at an early stage.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a fault management apparatus and method, and more particularly to a recording medium storing a program for realizing these functions, and more particularly, to a method for detecting a fault occurring in software (program) running on a computer. It is suitable for use in a device for management.

[0002]

2. Description of the Related Art In software failure management in system development, work efficiency is improved when a bug (failure) in a program is found and debugged, or a mistake in a document is corrected. It is necessary to manage information necessary for debugging and the like, manage work, and the like, in order to achieve the appropriateness and the like. For this reason, software test tools may be required to incorporate a function for managing information on bugs.

[0003]

However, most of the conventional test tools merely compile a program being developed or have already been developed, and merely accumulate the obtained error information so that it can be referred to. .

[0004] For this reason, a developer or the like has manually performed analysis of some failures that have occurred in certain software and graphing them based on the analyzed contents. Then, the developer himself judged whether there was any problem with reference to the manually created graph. For this reason, the presence or absence of the abnormality can be understood only when the graph is formed, so that there is a problem that it takes much time to take measures against the failure.

In addition, for example, analysis results such as the occurrence of a failure in a series of development processes and how the countermeasure work is being performed, and at what stage of each process the failure has occurred, and the like. If you look at the graph as a graph, it is not possible to determine whether it is normal or abnormal even if you analyze it too early. Therefore, the analysis work may not be meaningful in spite of the trouble. Furthermore, if data analysis and graphing work is performed at a stage where development has progressed considerably or after development has been completed, it is too late to take measures for the program development process etc. based on the analysis results. There was also a problem.

The present invention has been made to solve such a problem, and automatically collects and analyzes information relating to various types of faults occurring on software, and evaluates and presents the results. A first object is to provide a mechanism so that work such as troubleshooting can be performed more efficiently. In addition, the present invention provides a method of presenting a user with a progress status of a fault measure using the analysis result of the information on the fault described above.
The purpose of.

[0007]

According to the present invention, there is provided a fault management apparatus comprising: a storage unit for storing information relating to various types of faults occurring on software; and an information collection unit for collecting necessary information from the storage unit. Analysis / evaluation means for analyzing the collected information and comparing the analysis result with an evaluation criterion prepared in advance, and a result output means for outputting the result of the analysis / evaluation. It is characterized by having.

The analyzing / evaluating means analyzes the change in the number of fault occurrences, and compares the analysis result with an evaluation criterion prepared in advance to evaluate the presence or absence of an abnormality. Is also good. In addition, the analysis / evaluation means classifies various failures for each cause of occurrence, analyzes the respective ratios, and evaluates the presence or absence of abnormality by comparing the analysis result with an evaluation standard prepared in advance. It may be. In these cases, the result output means may include means for displaying the results analyzed by the analysis / evaluation means in a graph. Further, the result output means may include a means for giving a warning notification when the result analyzed by the analysis / evaluation means differs from an evaluation criterion prepared in advance beyond an allowable range. .

According to another aspect of the present invention, there is provided a report registering means for creating various reports and registering them in the storage means when performing a task for a fault, and the report includes information on the cause of the fault. It is characterized in that it is not registered. Further, an input form defining means for defining a form including an input item of the cause of the failure may be provided, and the report may be created using the defined input form.

In another aspect of the present invention, the analysis / evaluation means analyzes the number of completed countermeasures against a fault and compares the analysis result with an evaluation criterion prepared in advance to take a countermeasure against the fault. It is characterized by evaluating the quality of software. Here, the result output means includes:
It may include a means for graphically displaying the transition of the number of completed failure measures analyzed by the analysis / evaluation means. In this case, the result output means includes the analysis /
A quality level of the number of completed measures prepared in advance as the evaluation criterion may be displayed together with a graph of the transition of the number of completed completed measures by the evaluation means. Further, the result output means includes means for issuing an approval notification when the number of completed measures analyzed by the analysis / evaluation means reaches a quality level of the number of completed measures prepared in advance as the evaluation criterion. It may be something.

Further, the fault management method according to the present invention includes an information collecting step of collecting necessary information from storage means for storing information relating to various types of faults occurring on software, and analyzing the collected information. , An analysis that compares the analysis results with evaluation criteria prepared in advance
An evaluation step and a result output step of outputting a result of the analysis and evaluation are provided.

Further, a computer readable recording medium according to the present invention comprises a storage unit for storing information relating to various failures occurring on software, and an information collection unit for collecting necessary information from the storage unit. An analysis / evaluation means for analyzing the collected information and comparing the analysis result with an evaluation criterion prepared in advance, and a computer functioning as a result output means for outputting the analysis / evaluation result A program for causing the program to be recorded.

Since the present invention comprises the above technical means, it is possible to instruct the apparatus to perform analysis / evaluation processing without manually performing operations such as analysis of failures generated on software and graphing. For example, data collection and analysis and evaluation of the collected data are performed automatically. This process can be executed at any stage in the series of development process, and if any abnormality is detected as a result of comparison between the analysis result and the evaluation standard, the fact is notified immediately. Becomes

According to the present invention, the quality of software that has taken measures against failures is evaluated by analyzing the number of completed measures against failures and comparing the analysis result with an evaluation criterion prepared in advance. According to another feature, the progress of the countermeasure against the failure is presented to the developer, and, for example, when the removal of the failure reaches the quality target, the fact is immediately notified. . In addition, according to another feature of the present invention in which the result of analysis / evaluation and an evaluation criterion prepared in advance are displayed together, by comparing and referencing the two, the degree of progress of the countermeasure work for the failure can be determined. The end time of the test and the like can be easily grasped.

[0015]

DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment of the present invention will be described below with reference to the drawings. (First Embodiment) FIG. 1 is a block diagram showing an example of a main functional configuration of a fault management device according to the present embodiment.

In FIG. 1, an input form definition unit 1
Input form 2 for reports submitted by users such as developers and managers when performing software fault management
(Various forms used for purposes such as failure registration, failure countermeasure report, and countermeasure completion report) are defined. Here, a template that lists necessary items to be input in a report submitted by a user is defined for each stage of each operation performed in response to a failure.

For example, the template of the fault registration form includes input items such as a report submission date, a fault name, a fault occurrence target environment, a symptom, a measure deadline, and a degree of importance. In addition, the templates of the fault countermeasure report form and the countermeasure completion report form include input items such as a report submission date, a fault name, a fault cause, a countermeasure content, a version number of a corrected program, and a man-hour for correction.

The form input unit 3 obtains a form corresponding to the contents of a report to be submitted from several types of input forms 2 defined and stored in advance, and stores the form in each item in the obtained input form. By filling in necessary items, various reports (failure report, countermeasure report, countermeasure completion report, etc.) are created and submitted. Each time a report is submitted by the form input unit 3, the report registration unit 4 registers the report in the database 5.

As a result, a certain 1 is stored in the database 5.
For some failures on one software,
As the work of the countermeasure progresses from the detection of the fault, a fault report, a countermeasure report, a countermeasure completion report, and the like are sequentially accumulated for each fault. Further, when there are a plurality of target software, various reports regarding the failure are accumulated for each software.

The data collection unit 6 collects necessary information from the database 5 in which various types of report information are stored. The necessary information is information to be used in an analysis process to be performed. For example,
When analyzing the number of failures related to a certain software, only the information of the failure report submitted when performing the failure registration for the target software is collected.

When analyzing the number of completed countermeasures for a failure, only the information of the countermeasure completion report submitted when reporting the completion of the countermeasure for the target software is collected. When analyzing the ratio of the causes of various failures, only the information of the countermeasure report submitted when reporting the countermeasure for the target software or the above-described countermeasure completion report is collected.

The analysis / evaluation execution unit 7 analyzes the information collected by the data collection unit 6, compares the analysis result with the data of the evaluation criterion 8 prepared in advance, and determines whether there is any abnormality or not, The evaluation of quality etc. is performed. The analysis result output unit 9 outputs the result of the analysis / evaluation. For example, processing such as graphing the analyzed result and displaying it on a display device (not shown) or issuing a warning notification when the analyzed result differs from the evaluation criterion 8 beyond a certain allowable range is performed.

In the present embodiment, the analysis / evaluation execution unit 7 analyzes the reliability growth curve for the occurrence of a failure (analysis of the transition of the number of occurrences of failures and the number of completions of countermeasures), and classifies the failures to which they belong ( Two types of analysis can be performed. The user can arbitrarily specify which analysis is to be performed, for example, by operating a menu or the like displayed on a screen of a display device (not shown).

First, an analysis of a reliability growth curve for the occurrence of a fault will be described. FIG. 2 is a diagram showing an output example of the reliability growth curve. In the graph shown in FIG. 2, the horizontal axis indicates the passage of time, and the vertical axis indicates the number of cases. FIG. 2 shows three line graphs. Of these, ◆
The line graph A plotted with the symbol and the line graph C plotted with the symbol ● indicate the number of faults that have occurred for a certain software (the number of registered fault reports), and the line graph B plotted with a triangle indicates the fault measures completed for a certain software. (Number of registered countermeasure completion reports).

It is empirically known that when a test is performed on necessary test items by using an appropriate test tool using ordinary software, the number of faults changes as shown by a line graph A. That is, the number of failure occurrences suddenly occurs immediately after the start of the test (first phase), and after a short time, the number increases at a stretch (second phase), and after a considerable time after the start of the test, the increase rate decreases ( Third phase). Then, when the final phase of the test is reached, a saturation state is reached (fourth phase).

On the other hand, the case where the number of failure occurrences gradually increases from the beginning of the test as shown in the line graph C or the case where the number of failure occurrences continuously increases from the beginning (line graph C) Is not shown), the target software itself has a fundamental problem, the wrong test tool is used, the number of test items is small, etc. Often there is a problem with the way of testing.

Therefore, in the present embodiment, as the data of the evaluation criterion 8, the value of the slope in each phase of a graph following a normal transition such as a line graph A is stored in advance. The analysis / evaluation execution unit 7 compares the slope of the graph obtained as a result of analyzing the failure report collected from the database 5 with the value of the slope prepared in advance as the data of the evaluation criterion 8. Are different from each other beyond a predetermined allowable range, the analysis result output unit 9 issues some warning notification.

For example, as a result of executing the above-described analysis / evaluation processing as of June 19, if the number of occurrences of a failure has changed as indicated by a line graph C, a warning is immediately issued at this time. Notification is given. As a result, a software developer or the like can recognize that there is a problem in the software itself or a test method, and can immediately take a countermeasure against the problem.

In this case, for example, the number of occurrences of failures increases only gradually as shown by a line graph C, or the number of occurrences of failures increases from the beginning.
Even for the same abnormality, the slope of the graph is variously different. In other words, there are various causes of the occurrence of the abnormality, and the inclination of the graph varies depending on the type of the abnormality. Therefore, by empirically generalizing the correspondence between the type of abnormality and the inclination and storing the information, it is possible to output a different comment according to the inclination. In this way, appropriate measures for the problem can be easily taken.

On the other hand, when the inclination of the graph obtained as a result of the analysis of the number of failure occurrences by the analysis / evaluation execution unit 7 matches the inclination of the evaluation criterion 8, or the difference falls within a predetermined allowable range. In the case, in the analysis result output unit 9,
The analysis result by the analysis / evaluation execution unit 7 is graphed and displayed on a screen of a display device (not shown). Alternatively, the data may be printed on a paper medium or the like by a printing device (not shown) and output.

When the analysis result of the number of failure occurrences by the analysis / evaluation execution unit 7 is displayed as a graph, the analysis result of the number of completed measures against the failure is also graphed and displayed. That is, the analysis / evaluation execution unit 7 analyzes the number of failure reports collected from the database 5 and also analyzes the number of countermeasure completion reports collected at the same time, and displays the result on the screen by the analysis result output unit 9. . As a result, a software developer or the like can easily know how much time and how much trouble has occurred and how much countermeasures have been taken against it.

Further, by looking at the part of the fourth phase in which the number of failure occurrences finally does not change much,
You can also determine when to end the test and predict the total number of faults that will eventually occur. It is not the same for all software and programs that the quality of the software can be assured as a percentage of the total number of problems that can be eliminated. , Characteristics, etc. Therefore, if the total number of faults that can occur can be predicted, it is possible to determine, by referring to the current number of completed countermeasures, how much more faults should be removed before the product can be released.

The total number of faults that can occur can be roughly estimated according to the scale of the target software, that is, the number of program lines. Thus, a predetermined ratio (for example, 80%) to the total number of failures predicted from the number of program lines
%), A releaseable line serving as a guideline of the quality target may be displayed in the part of the number obtained by multiplying the number.
By doing so, it becomes clearer how much more obstacles can be released before the release can be performed, and the release can be performed even if the analysis / evaluation processing is performed at an early stage of the first to third phases. It is possible to know the number of remaining failure removals required until the state is reached.

The number of cases obtained by multiplying the total number of faults predicted from the number of lines of the target program by a predetermined ratio is stored as evaluation criterion 8 data.
Then, it is determined whether or not the number of countermeasure completion reports analyzed by the analysis / evaluation execution unit 7 exceeds the number of evaluation criteria 8 described above. May be output. In this way, it is possible to know whether or not release is possible at the time of executing the analysis / evaluation processing, without looking at the graph as shown in FIG.

Next, the analysis of the defect classification ratio will be described. FIG. 3 is a diagram showing an output example of the result of analyzing the ratio of the defect classification. In FIG. 3, the ratio of occurrence of each failure cause such as a defect in a mounting function, a defect in a coding, a defect in a specification, a defect in a system integration, a defect in a system architecture, and a defect caused by data definition / reference is shown. The example which output by making a pie chart is shown.

Which fault is caused by which cause is
Failures are investigated and countermeasures are performed by the developer, and are described in the countermeasure report or countermeasure completion report submitted as a result. Therefore, if the data collection unit 6 collects a countermeasure report or a countermeasure completion report from the database 5 for each cause of the failure, and the analysis / evaluation execution unit 7 accumulates the collection results individually,
It is possible to analyze the rate of occurrence of failures for each cause.

With respect to the defect classification ratio, it is empirically known which classification of a fault occurs and at what ratio when there is no abnormality in a test or the like. Therefore, in the present embodiment, a value of a normal ratio of each classification is prepared in advance as data of the evaluation criterion 8. Then, the analysis / evaluation execution unit 7 compares the ratio of each classification obtained as a result of analyzing the countermeasure report or the like collected from the database 5 with the value of the ratio prepared in advance as the data of the evaluation criterion 8. If the ratios of the two are different from each other beyond a predetermined allowable range, the analysis result output unit 9
Make some warning notification from.

Since the analysis of the ratio of defect classification is to see at what stage and how many failures have occurred in a series of software development processes, the stage at which development has been completed to the end This is usually done with However,
If the total number of faults that occur according to the scale of the software can be predicted, it can be performed in the middle of the development process. In other words, even if analysis and evaluation are performed in the middle of the development process, it is possible to know the ratio of faults that have occurred up to that stage to the total number of expected faults. It is possible to do.

FIG. 4 is a flowchart showing the operation of automatic data collection and analysis / evaluation. In FIG.
First, in step S1, specific information is collected from a data file in the database 5 according to the type of analysis to be performed, and is analyzed. FIGS. 5 and 6 are flowcharts showing a specific processing procedure in step S1. FIG. 5 shows a processing procedure for analyzing a reliability growth curve, and FIG. 6 analyzes a defect classification occurrence rate. The processing procedure at the time is shown.

For example, when analyzing the reliability growth curve, the data collection unit 6 first collects the submission date of the failure report stored in the database 5 from the data file in step S11 of FIG. In step S12, the submission date of the measure completion report also stored in the database 5 is collected from the data file. next,
In step S13, the analysis / evaluation execution unit 7 accumulates the number of each report for each submission date of the information collected in steps S11 and S12.

When analyzing the ratio of defect classification,
First, in step S21 in FIG. 6, the data collection unit 6 collects the defect classification result (cause of failure) of the countermeasure completion report stored in the database 5 from the data file. Next, in step S22, the analysis / evaluation execution unit 7
The number of each report is accumulated for each classification item of the information collected in step S21. Further, in step S23, based on the number of cases accumulated for each classification item in step S22, the ratio to the total number of each is calculated.

As described above, when data collection and analysis are completed according to the flow of FIG. 5 or FIG. 6, the process proceeds to step S2 of FIG. 4, and the analysis result is compared with the data of the evaluation criterion 8. Then, in step S3, whether the result of the comparison is normal, that is, whether the data obtained as a result of the analysis by the analysis / evaluation execution unit 7 matches the data of the evaluation criterion 8, or the difference is within a predetermined allowable range To determine if it fits.

If the result of the comparison is normal, the process proceeds to step S4, where the analysis result output unit 9 outputs the analysis result to a display device (not shown). This allows
A graph as shown in FIG. 2 or FIG. 3 is displayed on the screen of the display device. On the other hand, if the result of the comparison is not normal, the process proceeds to step S5, and the analysis result output unit 9 issues a predetermined warning notification. At this time, as described above, it is possible to output a different warning message depending on how the analysis result is different from the evaluation criterion 8.

As described in detail above, the fault management system of this embodiment automatically collects and analyzes information on various faults from the database 5 and compares the analysis results with the evaluation criteria prepared in advance. In addition to comparing and evaluating the results, the results of analysis and evaluation are displayed on a display device, etc., so that the trouble management device can Since the presence / absence of an abnormality is automatically determined based on the evaluation criterion 8, it is possible to instantly understand the analysis contents. Further, by executing analysis / evaluation processing at an arbitrary stage in a series of development processes, it is possible to immediately know whether or not there is an abnormality, and to take appropriate countermeasures at an early stage.

(Second Embodiment) Next, a second embodiment of the present invention will be described. In a second embodiment described below,
This is an application of the fault management device described in the first embodiment to a fault management system in the form of a client-server system. The fault management system according to the second embodiment has a function of storing management information of a series of fault measures in addition to the information on faults, and monitoring and managing whether measures have been appropriately taken. This function is realized by using a so-called workflow system that shares information related to office work between departments and manages the flow of the information.

FIGS. 7 and 8 are block diagrams showing an example of the configuration of a fault management system according to this embodiment. FIG. 7 shows a schematic configuration of the entire system, and FIG. 8 shows a detailed functional configuration in the system. Is shown. 7 and 8
In FIG. 7, components denoted by the same reference numerals as those shown in FIG. 1 have the same functions.

As shown in FIG. 7, in the fault management system according to the present embodiment, a plurality of client machines (hereinafter, abbreviated as clients) 10, 10,... It is configured as a client / server system connected via the PC 40. Further, a terminal 30 for an administrator who manages the failure management system is connected to the server 20. Further, the server 20 includes a database 21 for storing fault management operation data including various reports described above and information on a transition state of a workflow described later.

As shown in FIG. 8, an input form definition unit 1, a workflow definition unit 31,
A collection information definition unit 32, an evaluation criterion definition unit 33, and a warning definition unit 34 are provided. As described above, the input form definition unit 1 defines several types of input forms for a report submitted by the user when performing software fault management. The input form 2 defined here is given to the server 20 and stored.

Further, the workflow definition unit 31 divides the information relating to the fault management work between the application software development department and the usage department, etc., and takes measures against the fault in what procedure. This is to define a workflow that indicates the number of times. The file of the workflow model 26 defined here is also given to the server 20 and stored.

The collection information definition unit 32 defines information necessary when data is analyzed by the analysis / evaluation execution unit 7, that is, which data in the database 21 is required for which analysis processing. For example, when analyzing the number of failure occurrences, the information in the failure report is used. When analyzing the number of completed measures for the failure or when analyzing the ratio of the causes of various failures, the information in the measure completion report is included.
Defined as information needed for analysis. The collection information definition file 27 created here is also given to the server 20 and stored.

The evaluation criterion definition unit 33 defines the data of the evaluation criterion 8 described above, and includes the slope of the reliability growth curve in each phase, the occurrence ratio for each defect classification,
Define the number of completed measures as a guide to product release quality assurance. In addition, the warning definition unit 34 stores the correspondence between the type of abnormality (such as an abnormality in the software itself or the abnormality in the test method) and the analysis result (such as the above-described inclination and ratio), a warning message corresponding to the type of the abnormality, and the like. Warning definition file 28
Is defined as The evaluation criteria 8 and the alert definition file 28 created here are also given to the server 20 and stored.

On the client 10, general-purpose browser software based on the Web (Web) is running. As shown in FIG. 8, the browser software includes an input form request unit 11, a form transmission unit 12, a notification reception unit 13, and an analysis result display unit 14 as functions. Note that the notification receiving unit 13 may be realized as a function of general-purpose mail software. This client 1
0 is used by various users belonging to the software development department and its use department.

The client 10 according to the present embodiment only needs to have a general-purpose web-based or mail-based program for managing software failures.
A workflow program for fault management need not be provided at all. On the other hand, the server 20 includes a program for inputting and outputting data via the web and e-mail, and a workflow program for failure management. That is,
In the present embodiment, only the server 20 has a workflow program for failure management.

The input form requesting section 11 is a server
This is for requesting the acquisition of a desired form from among the various input forms 2 stored in the area 0, and has, for example, a browser button displayed on the screen.
When this browser button is clicked with a mouse and a desired form is designated, the designated input form 2 is sent from the server 20. The input form 2 is transmitted as, for example, an HTML browser screen itself.

The form transmission unit 12 creates a report by filling in necessary items in the respective items in the input form 2 obtained as described above, and sends the report to the server 20 in the HTML format. The notification receiving unit 13 receives a notification of a failure countermeasure work instruction, which will be described later, and a warning notification transmitted from the server 20. In addition, the analysis result display unit 14 displays the results analyzed by the analysis / evaluation execution unit 7 in a graph.

Next, the configuration inside the server 20 will be described. The form analysis unit 22 converts the form of the report sent from the form transmission unit 12 of the client 10 into a form
The analysis is performed by referring to the input form 2 stored in the server 20. Then check what kind of form it is. This form analysis unit 44
Also, based on the information written in the report, it analyzes which fault the report is for, the cause of the failure, and the like.

The workflow state determination unit 23 reads information representing the transition state of the workflow stored in the database 21, and further, based on the definition information of the workflow model 26, the report given from the client 10, etc. This is to determine what the current state is in the workflow for each fault that has occurred. For example, the initial state of failure registration, the investigation of the cause of the failure, the response to the failure, the suspension of the response,
It is determined which of the states such as countermeasure completion is currently in place.

The workflow state transition processing unit 24 executes processing for transitioning the state of the workflow each time a report is given after a certain process is performed by a person in charge of failure management or an administrator. This is performed by changing to the next state according to the content of the report sent from the client 10 according to the defined workflow model 26. The updated transition state information is stored again in the database 21 together with the given report.

The workflow state transition processing unit 2
4 also performs a process of notifying the next client instruction to the appropriate client 10 defined by the workflow via the notification unit 25 according to the defined workflow model 26. This work instruction may indicate the work to be performed next by transferring the report given from one client to another client as it is, or create and send a clear work instruction Is also good. This notification may be made on a mail basis instead of a web basis.

The notifying unit 25 also notifies the workflow model 26 that the state has been changed when the state of the workflow related to a certain failure has been changed by the workflow state transition processing unit 24. Client 10 of user defined as in scope
Is also performed. Further, according to the result of the analysis / evaluation performed by the analysis / evaluation execution unit 7, a process of notifying a warning message or an approval message is also performed.

Hereinafter, a workflow operation in the fault management system according to the present embodiment configured as described above will be described. First, when any trouble (bug) is found, for example, when the created application is used on a certain client 10 or a user terminal (not shown), the user reports the found trouble. In order to obtain the fault registration form to be used at that time from the input form 2 of the server 20, the user who has found the fault sends a request to obtain the form from the input form requesting unit 11 of the client 10 used by the user. Send to

When the server 20 receives the form acquisition request, the server 20 determines whether the requested fault registration form exists in the various input forms 2. Here, if the requested failure registration form exists, the failure registration form template is transmitted to the requesting client 10.

When the client 10 receives the fault registration form, the user creates a fault report by describing necessary items in each item in the form, and transmits it to the server 20 from the form transmitting unit 12. When the server 20 receives the failure report,
The processing of the workflow described below is executed.

That is, first, the form of the received report is analyzed by the form analysis unit 22, and a fault for the report is specified. Then, the workflow state determination unit 23 determines the current state of the workflow regarding the specified failure according to the type of the report or the like. In the present example, since a failure report has been received, it is determined that this is the initial stage of first registering the failure that has occurred.

Next, the workflow state transition processing unit 24
Changes the current state of the failure to be processed in the workflow to the next state. In the example in which the trouble report has just been registered, the state of the workflow is changed from the initial state before the trouble occurrence to the state under investigation. At this time, the updated transition state information is stored in the database 21 together with the given report. Further, the workflow state transition processing unit 24 uses the notification unit 25 and uses the appropriate user defined in the workflow model 26 (in this example, a person who should take measures against a failure).
Of the next fault management work instruction to the client 10.

The person in charge (system developer) receiving such a fault management operation instruction (fault report) takes necessary measures to resolve the reported fault.
For example, the program is modified as needed. If any countermeasure is taken, it is described as a countermeasure report and transmitted to the server 20. At this time, the person in charge
The trouble countermeasure report form is obtained from the input form 2 of the server 20. Then, a necessary countermeasure report is created by describing necessary items in each item of the obtained fault countermeasure report form, and the prepared report is transmitted to the server 20.

When the server 20 receives the countermeasure report created based on the fault countermeasure report form, the server 2
0 is the same as when the failure report is received, the form analysis unit 22 detects the correspondence with the failure by analysis, and the workflow state determination unit 23 and the workflow state transition processing unit 24 change the current state of the workflow to the next state. (In this example, the status changes from during cause investigation to countermeasures). Also at this time, the updated transition state information is stored in the database 21 together with the given report.

Further, the server 20 detects the user to whom the received countermeasure report is to be sent next according to the workflow model 26, and transmits it to the client 10 of an appropriate user (for example, an administrator). The user of the client 10 receiving this determines whether there is a problem with the report of the countermeasure report, and if there is a problem, gives an instruction to return the correspondence. On the other hand, if there is no problem in the report, a countermeasure completion report is transmitted, and the state of the workflow is transited to “countermeasure completed”.

Here, an example is shown in which the person in charge of receiving the failure report immediately takes necessary measures. However, the cause of the failure is reexamined, and opinions on the failure are exchanged with other persons in charge. Or temporarily suspending countermeasures due to the occurrence of another emergency that requires urgency. In such a case as well, the input form 2 corresponding to those aspects is obtained from the server 20 to the client 10, and a report prepared by describing necessary items is returned to the server 20. The server 20 transitions the state of the workflow in accordance with the sent report, and notifies the appropriate user of the report according to the workflow.

As described above, as the workflow processing of the fault management proceeds, the database 21 stores a fault report, a countermeasure report, a countermeasure completion report, and the like for each of the faults generated on the software. Are sequentially accumulated. In this case, when the countermeasure report and the countermeasure completion report are registered in the database 21, the cause of the failure is detected by the form analysis unit 22, so that those reports are classified according to the cause of the failure, the importance of the failure, and the like. May be stored separately.
In this way, data collection for the subsequent analysis can be efficiently performed.

Regarding the contents of automatically executing data collection and analysis / evaluation processing by the data collection unit 6 and the analysis / evaluation execution unit 7 for various types of report information stored in the database 21, Since it is as described in the first embodiment, detailed description is omitted here.

However, when data is collected by the data collection unit 6, only necessary information defined in the collection information definition file 27 is collected. The analysis / evaluation execution unit 7
As a result of analysis and evaluation by
An appropriate warning message is issued via the notification unit 25 according to the contents described in the warning definition file 28. On the other hand, if the diagnosis result is not abnormal, the analysis result is provided from the server 20 to the analysis result display unit 14 of the client 10 and displayed.

As described above, according to the second embodiment,
The analysis / evaluation as described in the first embodiment can be executed by using the accumulated information in the workflow processing for managing not only the failure information itself but also information on countermeasures against the failure. This makes it possible to further improve the efficiency of a series of operations for system development.

Each of the embodiments described above is merely an example of the embodiment for carrying out the present invention, and the technical scope of the present invention is interpreted in a limited manner. It must not be. That is, the present invention can be embodied in various forms without departing from the spirit or main features thereof. For example, in the above embodiment, a line graph and a pie graph are shown as examples of the graph, but the graph is not limited to these graphs. Further, the content of the analysis is not limited to the number of occurrences of failures, the number of completed measures, the classification of defects, and the like.

The fault management apparatus according to each of the embodiments described above includes a computer CPU, MPU, RA
M, ROM, etc., RAM and RO
This can be realized by operating a program stored in M. Therefore, the present invention can be realized by recording a program that causes a computer to perform the above function on a recording medium such as a CD-ROM, and reading the program into the computer. As a recording medium, a floppy disk, a hard disk, a magnetic tape, a magneto-optical disk, a nonvolatile memory card, or the like can be used other than the CD-ROM.

Further, the functions of the above-described embodiments are realized not only by the computer executing the supplied program, but also the OS (operating system) or other application software running on the computer. When the functions of the above-described embodiment are realized in cooperation with the computer, or when all or a part of the processing of the supplied program is performed by a function expansion board or a function expansion unit of a computer, the functions of the above-described embodiment are realized. Such a program is also included in the embodiment of the present invention.

[0077]

As described above, according to the present invention, necessary information is automatically collected and analyzed from the storage means storing information on various faults, and the analysis result is compared with the evaluation criteria prepared in advance. And evaluate the results, and output the analysis / evaluation results to, for example, a display device, so that analysis / evaluation processing can be performed without manually performing work such as failure analysis and graphing. Is automatically executed by the apparatus, the analysis contents such as the presence or absence of an abnormality can be immediately known. In addition, analysis and evaluation processing can be executed at an arbitrary stage in a series of development processes, and when an abnormality is found, appropriate measures can be taken early and appropriately.

According to another feature of the present invention, the number of completed countermeasures against a failure is analyzed, and the result of the analysis is compared with an evaluation criterion prepared in advance, so that the software for which the countermeasure against the failure has been performed is analyzed. Since the quality is evaluated, the developer can immediately know the progress of the countermeasures against the failure. In addition, the results of the analysis and evaluation are displayed together with the evaluation criteria prepared in advance. By comparing and referencing the two, the degree of progress of the countermeasure work for the failure and the end time of the test are displayed. Can be easily grasped.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a detailed functional configuration example of a fault management device according to a first embodiment.

FIG. 2 is a diagram showing an output example of a result of analyzing a reliability growth curve.

FIG. 3 is a diagram showing an output example of a result of analyzing a defect classification ratio.

FIG. 4 is a flowchart showing an operation of automatic data collection and analysis / evaluation.

FIG. 5 is a flowchart showing a processing procedure when analyzing a reliability growth curve in step S1 of FIG. 4;

FIG. 6 is a flowchart showing a processing procedure when analyzing a defect classification ratio in step S1 of FIG. 4;

FIG. 7 is a block diagram illustrating a schematic configuration of an entire fault management system according to a second embodiment.

FIG. 8 is a block diagram illustrating a detailed functional configuration example of a fault management system according to a second embodiment.

[Explanation of symbols]

 1 Input Form Definition Part 2 Input Form 3 Form Input Part 4 Report Registration Part 5 Database 6 Data Collection Part 7 Analysis / Evaluation Execution Part 8 Evaluation Criteria 9 Analysis Result Output Part 10 Client Machine 11 Input Form Request Part 12 Form Transmission Part 13 Notification Receiving unit 14 Analysis result display unit 20 Server machine 21 Database 22 Form analysis unit 23 Workflow status judgment unit 24 Workflow status transition processing unit 25 Notification unit 26 Workflow model 27 Collection information definition file 28 Warning definition file 30 Administrator terminal 31 Workflow definition Part 32 collection information definition part 33 evaluation criteria definition part 34 warning definition part 40 network

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Yoshimasa Saito 2-6-3 Otemachi, Chiyoda-ku, Tokyo Inside Nippon Steel Corporation (72) Inventor Ken Kikata 2-6, Otemachi, Chiyoda-ku, Tokyo 3 Nippon Steel Corporation F-term (reference) 5B042 HH11 HH20 JJ30 KK13 LA08 MA14 MC28 NN08

Claims (19)

[Claims] A storage unit for storing information relating to various types of faults occurring on software; an information collection unit for collecting necessary information from the storage unit; and analyzing the collected information. A fault management device, comprising: analysis / evaluation means for performing an evaluation by comparing a result with an evaluation criterion prepared in advance; and a result output means for outputting a result of the analysis / evaluation. 2. The analysis / evaluation means analyzes a change in the number of fault occurrences and evaluates the presence or absence of an abnormality by comparing the analysis result with an evaluation criterion prepared in advance. The fault management device according to claim 1. 3. The fault management device according to claim 2, wherein said result output means includes means for displaying a graph of a change in the number of fault occurrences analyzed by said analysis / evaluation means. 4. The analysis / evaluation means classifies the various failures for each cause and analyzes the respective ratios, and compares the analysis result with an evaluation criterion prepared in advance to determine whether there is an abnormality. The fault management device according to claim 1, wherein the fault management device is evaluated. 5. The fault management according to claim 4, wherein said result output means includes means for displaying a graph of a fault occurrence ratio for each classification analyzed by said analysis / evaluation means. apparatus. 6. The result output means includes means for issuing a warning notification when the result analyzed by the analysis / evaluation means differs from an evaluation criterion prepared in advance beyond an allowable range. The fault management device according to claim 1. 7. A report registering means for creating various reports and registering them in the storage means at the time of performing a task for a failure, wherein the report includes information on the cause of the failure and registers the reports. The fault management device according to claim 4 or 5, wherein 8. An input form defining means for defining a form including an input item of the cause of the failure, wherein the report is created using the defined input form. Item 8. The fault management device according to Item 7. 9. The analysis / evaluation means analyzes the number of completed countermeasures against a failure, and compares the analysis result with an evaluation criterion prepared in advance to evaluate the quality of software that has taken the failure countermeasure. The fault management device according to claim 1, wherein 10. The system according to claim 9, wherein said result output means includes means for graphically displaying a transition of the number of completed failure measures analyzed by said analysis / evaluation means.
The fault management device according to 1. 11. The result output means displays a quality level of the number of completed measures prepared in advance as the evaluation criterion, together with a graph of a change in the number of completed measures by the analysis / evaluation means. The fault management device according to claim 10. 12. The result output means sends an approval notification when the number of completed measures analyzed by the analysis / evaluation means reaches a quality level of the number of completed measures prepared in advance as the evaluation criterion. The fault management apparatus according to any one of claims 9 to 11, further comprising means. 13. An information collecting step of collecting necessary information from storage means storing information on various failures occurring on software; analyzing the collected information; A failure management method, comprising: an analysis / evaluation step of performing an evaluation by comparing with an evaluation criterion being performed; and a result output step of outputting a result of the analysis / evaluation. 14. The analysis / evaluation step is characterized in that a transition in the number of failure occurrences is analyzed, and the presence or absence of an abnormality is evaluated by comparing the analysis result with an evaluation criterion prepared in advance. The fault management method according to claim 13. 15. In the analyzing / evaluating step, various failures are classified for each cause of occurrence, the ratio of each is analyzed, and the analysis result is compared with an evaluation criterion prepared in advance to determine whether there is an abnormality. 14. The fault management method according to claim 13, wherein evaluation is performed. 16. In the result output step, if the result analyzed by the analysis / evaluation means differs from an evaluation criterion prepared in advance beyond an allowable range, a warning notification is issued, and the difference between the two is allowed. 16. The fault management method according to claim 14 or 15, wherein when the value is within the range, the result analyzed by the analysis / evaluation means is displayed as a graph. 17. In the analyzing / evaluating step, the number of completed countermeasures against the failure is analyzed, and the analysis result is compared with an evaluation criterion prepared in advance to evaluate the quality of the software that has taken the failure countermeasure. The fault management method according to claim 13, wherein: 18. In the result output step, when the number of completed measures analyzed in the analysis / evaluation step has reached the quality level of the number of completed measures prepared in advance as the evaluation criterion, an approval notification is issued. 18. The fault management method according to claim 17, wherein: 19. A storage unit for storing information relating to various failures occurring on software; an information collection unit for collecting necessary information from the storage unit; and analyzing the collected information. Analysis / evaluation means for performing an evaluation by comparing the result with an evaluation standard prepared in advance, and a program for causing a computer to function as a result output means for outputting the result of the analysis / evaluation, is recorded. Computer readable recording medium.