JP4642553B2 - Software module failure impact analysis device, failure impact analysis method, and failure impact solution program - Google Patents

Description

  The present invention relates to a software module failure impact analysis apparatus, failure impact analysis method, and failure impact solution program, and in particular, performs failure impact analysis of a software product typified by ERP (Enterprise Resource Planning) package software. Regarding technology. Further, the present invention relates to a technique for efficiently performing defect influence analysis between versions in an environment where there are multiple versions of software and software customized (modified) according to customer requirements.

When a defect occurs in a software product, in order to take measures against the defect, first, a module in the software in which the defect exists is specified. Therefore, a method for efficiently investigating where a defect exists in a program step in a specified module has been proposed (see Patent Document 1).
JP-A-7-134664

  With software products typified by ERP packaged software, various versions of modules are operated by customers of the software product introduction destination due to version upgrade after product release. It is up to the customer to upgrade or not, so the latest version of the module is not always running. In addition, at the time of introduction to the customer, there are cases where the modules constituting the software product are customized (modified) in accordance with the customer's required specifications.

  In this way, in an environment where various versions of modules and customized modules exist, when a failure occurs in a specific version of the module, there is almost no case where only the module of that version needs to be targeted. In this case, it is necessary to investigate all versions of modules and customized modules related to the module in which the failure occurred.

  Such work is performed by software product developers through various investigations and countermeasures, but the range of modules to be investigated depends on the knowledge and skills of the product developer. Currently. In addition, customized modules may not be covered by product warranty and may not be subjected to failure analysis in the first place.

  However, a technique for efficiently investigating the presence / absence of a defective portion in a module across versions or after customization is not disclosed after the defective portion of the module is specified.

  The software module failure effect analysis device of the present invention that solves the above problems is a device that analyzes the failure effect that has occurred in the software module, and a failure location identifying unit that identifies the failure location of the failure occurrence module, The module master database that stores information on the parent-child relationship between modules based on the version is referenced, and the version of the parent module that is the basis for creating the failure occurrence module and the version that is derived from the failure occurrence module A parent-child version extracting unit that extracts a child module and a defective part remaining that confirms that the defective part specified by the defective part specifying unit remains in the version of the parent or child module extracted by the parent-child version extracting unit Check the output part Having an output unit for outputting a chair, a.

  In addition, the software module failure impact analysis apparatus of the present invention refers to a customer master database storing customer information of each version of the module, and the failure location remaining check unit confirms the presence of the failure location. It is preferable to have a defect notifying unit that extracts information on the customer of the version of the module and executes notification of remaining defective parts to the customer on the basis of the information of the customer.

  In addition, the software module failure effect analysis apparatus of the present invention includes: a module master database that stores customization information for each module; and a customer master database that stores relationship information between the delivery customer and the customization company. It is preferable to have a notification destination selection unit that refers to and selects the notification destination for notifying the remaining defective portion as either a delivery destination customer or a customizing company in accordance with the presence or absence of customization. .

  The software module failure effect analysis method of the present invention is a method of analyzing a failure effect generated in a software module by a computer, wherein the computer identifies a failure location of the failure occurrence module and converts it into a version. A module master database that stores information on a parent-child relationship between modules based on the version of the parent module that is the basis for creating the failure occurrence module, and a version of the child module that is derived from the failure occurrence module And confirms that the defective part remains in the version of the parent or child module, and outputs the result of the residual part remaining confirmation to the output interface.

The software module failure effect analysis program of the present invention is a program for causing a computer to execute a method of analyzing a failure effect generated in a software module, the step of identifying a failure location of the failure occurrence module; Referring to the module master database that stores information on the parent-child relationship between modules based on the version, the version of the parent module that is the basis for creating the failure occurrence module, and the version that is derived from the failure occurrence module A step of extracting the child module, a step of confirming that the defective portion identified by the step remains in the version of the parent or child module, and a result of the remaining confirmation of the defective portion on the output interface and outputting, the co According to a program to be executed by a computer.

  In addition, the problems disclosed by the present application and the solutions thereof will be clarified by the embodiments of the present invention and the drawings.

  According to the present invention, it is possible to efficiently investigate the influence range of defects occurring in a software module.

--- System configuration ---
Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a network configuration diagram including a software module failure effect analysis apparatus of this embodiment. In this network configuration example, the software module failure impact analysis apparatus according to the present invention, an automatic software distribution system 101 that performs failure impact analysis between software module versions and failure information distribution, is connected via a network 140. Software introduction site 103 as a customer computer as a software introduction destination, and software distribution relay server 102 and data communication provided by an internal department (meaning inside the software developer) in charge of the customer or an external partner company It is tied to possible.

  The automatic software distribution system 101 (hereinafter referred to as the system 101) includes a module master database 201, a customer master database 202, a customer introduction module database 203, defect information, in order to realize the software module failure effect analysis method of the present invention. Various databases such as a database (without customization) 204 and a defect information database (with customization) 205 are provided. Examples of the data structure of these databases will be described later.

  The software automatic distribution system 101 (hereinafter referred to as system 101), which is a software module failure effect analysis apparatus of the present invention, is a rewritable memory or the like to realize a function for executing the software module failure effect analysis method of the present invention. The program 12 such as the software defect influence analysis program 301, the software defect information distribution program 302, and the module information registration program 303 stored in the program database 11 is read into the memory 13 and executed by the CPU 14, which is an arithmetic unit in the system control unit 501. To do.

  The system 101 includes various keyboards and buttons generally provided in a computer device, an input / output interface 15 such as a display, and a communication means 16 for transferring data to and from the software distribution relay server 102. have. The input / output interface 15 outputs an input screen 401 and can accept an input from the user.

  The system 101 is connected to the software distribution relay server 102 and the like via the network 140 such as the Internet, a LAN, or a serial interface communication line by the communication means 106, and executes data exchange. Between the various function units of the system 101 and the communication means 16, the I / O unit 17 executes data buffering and various mediation processes.

  Subsequently, functional units that are configured and held by the system 101 based on the program 12, for example, will be described. The system 101 includes a defective part specifying unit 110 that specifies a defective part of a defective module. In addition, the system 101 refers to the module master database 201 that stores information on the parent-child relationship between modules based on the version, and from the parent module of the version that is the basis for creating the failure occurrence module, and the failure occurrence module A parent-child version extracting unit 111 that extracts a child module of a version created by derivation is provided.

  The system 101 also includes a defective part remaining check unit 112 that confirms that the defective part specified by the defective part specifying unit 110 remains in the version of the parent or child module extracted by the parent / child version extracting unit 111. Is provided.

  In addition, the system 101 includes an output processing unit 113 that outputs a result of the residual part remaining confirmation to an output interface.

  In addition, the system 101 refers to the customer master database 202 that stores information on the customers to whom each version of the module is delivered, and delivers the version of the module whose remaining defective portion has been confirmed by the defective portion remaining check unit 112. It is preferable to provide a defect notifying unit 114 that extracts information on a pre-customer and performs notification of the remaining defective part to the target customer based on the information on the customer.

  Further, the system 101 refers to the customization information of each module in the module master database 201 and the customer master database 202 that stores the relationship information between the delivery customer and the company in charge of customization, and performs the customization. It is preferable to provide a notification destination selection unit 115 that selects a notification destination for notification of the remaining defective portion as a delivery destination customer or a customization company depending on the presence or absence.

  The defective part specifying unit 110, the parent / child version extracting unit 111, the defective part remaining check unit 112, and the notification destination selecting unit 115 can be assumed as functional modules included in the software defect influence analysis program 301 shown in FIG. Further, the output processing unit 113 and the defect notification unit 114 can be assumed as functional modules included in the software defect information distribution program 302 shown in FIG.

  The functional units 110 to 115 in the system 101 described so far may be realized as hardware, or as a program stored in an appropriate storage device such as a memory or a HDD (Hard Disk Drive). Also good. In this case, the CPU 14 of the system 101 of the present invention reads the corresponding program 12 from the storage device into the memory 13 and executes it in accordance with the program execution.

  In addition to the Internet and LAN, the network 140 includes various types such as an ATM line, a dedicated line, a WAN (Wide Area Network), a power line network, a wireless network, a public line network, a mobile phone network, and a serial interface communication line. A network can also be adopted. If a virtual private network technology such as VPN (Virtual Private Network) is used, communication with improved security is established when the Internet is adopted. The serial interface refers to an interface for connecting to an external device by serial transmission that sequentially transmits data bit by bit using a single signal line, and RS-232C, RS-422, IrDA, USB, IEEE 1394, fiber channel, etc. can be assumed.

--- Database structure ---
Next, the structure of the database used by the system 101 of this embodiment will be described. FIG. 2 is a diagram showing a data structure of the module master database 201 in the present embodiment. The module master database 201 uses, for example, a module ID that uniquely identifies each module as a key, a module name, a version number, and the like. This is a set of records in which information such as a customization presence / absence flag indicating whether or not the information is customized and a parent module ID indicating the module ID of the module from which the information is derived are associated.

  FIG. 3 is a diagram showing a data structure of the customer master database 202 in the present embodiment. The master database 202 uses, for example, a customer ID that uniquely identifies a customer as a software installation destination as a key, a customer name, a customer contact name, a customer contact email address, a responsible department / partner, a responsible department / partner charge. This is a collection of records that relate information such as the person's name, department / partner contact person's email address.

  FIG. 4 is a diagram showing a data structure of the customer introduction module database 203 in the present embodiment. The customer introduction module database 203 is, for example, a collection of records in which information such as a module ID and a current use flag is associated with a customer ID as a key. The customer introduction module database 203 is a database for managing information of modules introduced to customers using the module ID of the module master database 201 and the customer ID of the customer master database 202 as keys. Note that the current use flag is a flag for identifying a module that is currently operating in a customer as an introduction destination.

  FIG. 5 is a diagram showing a data structure of the defect information databases 204 and 205 in the present embodiment. As the defect information database, two types of databases are assumed, where the module is customized (with customization) and not customized (without customization). Each defect information database 204, 205 includes, for example, a mail address of a person in charge, a target module in which a defect has occurred, and a version number of the target module, using the destination name of the defect information as a key. , Failure content, new version number of the module for which countermeasures have been taken. This is a collection of records in which information such as the location of a module with countermeasures (such as a URL) and the name of a developer responsible for inquiry are associated.

--- Main flow example ---
Hereinafter, the actual procedure of the software module failure effect analysis method according to the present embodiment will be described with reference to the drawings. Note that various operations corresponding to the software module failure effect analysis method described below are realized by the program 12 which the software module failure effect analysis system 101 reads into the memory 13 and executes. And this program 12 is comprised from the code | cord | chord for performing various operation | movement demonstrated below. FIG. 6 is a diagram illustrating an example of a main flow in the software module failure effect analysis method of the present embodiment. FIG. 7 is a conceptual diagram showing an image of software defect influence analysis, and FIG. 8 is a conceptual diagram showing an image of an input screen of the automatic software distribution system.

  In the present embodiment, as a premise for performing the defect influence analysis between versions of software modules, in the example shown in FIG. 7, when the base software module “Class1.java V1.0” is upgraded, Assume that the internal department or external partner company in charge of the customer to be installed will install the latest version of the module to the customer as needed. Further, the internal department or the external partner company customizes the module as necessary and installs it on the customer's computer.

  After such an installation process, the internal department and the external partner company access the system 101 with an appropriate terminal via an appropriate network 140 such as the Internet or an intranet. At that time, the terminal provided in the internal department or the external partner company uses the module information registration program 303 to display the necessary information on the input screen 401, etc. And accept the input. Here, the information received by the terminal is transmitted to the system 101, and for example, the corresponding modules in the module master database 201, the customer master database 202, and the customer introduction module database 203 are stored or updated information of existing information.

  Under the above assumption, it is assumed that a software module defect has occurred at the software installation site 103 of the customer as the software module installation destination. In this case, the defect location identifying unit 110 (in the software defect influence analysis program 301) in the system 101 accesses the software introduction site 103 via the network 140, and first, the contents of the defect, the module in which the defect has occurred, and the module Investigate and identify the defective parts. In addition, what is necessary is just to employ | adopt the function with the defect location identification technique proposed conventionally as the function of this defect location identification part 110. FIG.

  The investigation and identification result here is information on items such as the module ID, module name, version number, defect content, and program code related to the defective part, as shown in the input screen 401 (see FIG. 8). And is set in the memory 13 by the software defect influence analysis program 301 (step 301-1). Alternatively, the input screen 401 transmitted from the system 101 may be displayed on the software introduction site 103, and information input by a person in charge such as the internal department or an external partner company may be accepted through the input screen 401. In this case, the input information on the input screen 401 is transmitted from the software introduction site 103 to the system 101, and the system 101 sets it in the memory 13.

  In the example of FIG. 7, a defect has occurred in “Class 1. Java V1.0” in “E Corporation Introduced Module”. In this case, when the system 101 accepts information input from the input screen 401, the module ID “00001”, the module name “Class1.java”, the version number. Data of “V1.0”, failure content (contents of the failure content field 801 in FIG. 8), and program code (contents of the failure location field 802 in FIG. 8) relating to the failure location are received.

  Next, the parent / child version extracting unit 111 of the system 101 relates to the module identified by the module ID “00001” acquired in step 301-1, and is indicated by the parent module ID “−” of the module in the module master database 201. Information of the module IDs “00002” and “00005” of the child module having the module ID of the parent module and the module ID “00001” of the module as the parent module ID is acquired (step 301-2). The parent module ID “-” indicates that there is no parent module and that the module itself is the highest module.

  The system 101 executes an influence check (X) for the module having a parent-child relationship (referred to as module X) acquired as described above (step 301-3). The influence check (X) indicates a process for checking the remaining of a defective portion, which is performed on the module X by the defective portion remaining check unit 112 of the system 101 (step 301-4 to step 301-17). Further, the result of the remaining part remaining confirmation is output to an appropriate output interface by the output processing unit 113 of the system 101.

  Next, the influence check (X) will be described. Here, the system 101 searches the module X for the program code (the contents of the defective portion field 802 in FIG. 8) set in the memory 13 in step 301-1 to determine whether it is included in the module X (see FIG. 8). Step 301-4). In this search process, the system 101 uses a general character string comparison command such as “diff” provided by the operating system. Based on the result of this search process, the system 101 determines whether the module X contains a defective part (step 301-5). In this determination, when the module X includes a defective part (step 301-5: Yes), the system 101 acquires information on the customization presence / absence flag regarding the module X from the module master database 201 (step 301-6). ). Based on the customization presence / absence flag, the system 101 determines whether or not the module X has been customized (step 301-7).

  In the example of FIG. 7, it is searched whether the program code of the defective part (contents of the defective part field 802 in FIG. 8) is included in the two modules having the module ID “00002” and the module ID “00005”. Both indicate that a defective portion was included. Therefore, the system 101 acquires the customization presence / absence flag “0” of the module ID “00002” and the customization presence / absence flag “1” of the module ID “00005”, and determines that the module of the module ID “00005” is customized. .

  If the module X has been customized in the determination in step 301-7 (step 301-7: Yes), the system 101 executes a search using the module ID “00005” as a key in the customer introduction module database 203, The current use flag “0” and the customer ID “CUST01” are acquired (step 301-8).

  Based on the information on the current use flag, the system 101 determines whether the module X is currently used (step 301-10). If the module X is not used (step 301-10: No), step 301-16 is performed. Skip processing.

  On the other hand, if the module X is currently used (step 301-10: Yes), the system 101 executes a search in the customer master database 202 by the customer ID acquired in step 301-8, and the module X is currently Information such as the name of the customer in use, the department / partner in charge, the name of the department / partner in charge, and the department / partner email address is acquired (step 301-12).

  Further, the system 101 determines the information set in the memory 13 in step 301-1, the information acquired in step 301-12, the name of module X and the version number. Based on the above, data on the defective part is added in the defect information database (with customization) 205 (step 301-14). In this example, the system 101 searches the customer introduction module database 203 for the module having the module ID “00005” to obtain the current use flag “0”. However, the current use flag “0” is the module ID. Since the module “00005” means a module that is not currently used, the processing is skipped to step 301-16.

  On the other hand, if it is determined in step 301-7 that the module X has not been customized (step 301-7: No), the system 101 searches the customer introduction module database 203 using the module ID “00002” as a key. Executed to obtain information on the current use flag “0” and the customer ID “CUST03” (step 301-9).

  Here, the system 101 determines whether or not the module X is currently used based on the information of the current use flag acquired in the above step (step 301-11). If it is determined that the module X is not used (step 301-11: No), the system 101 skips the process to step 301-16.

  On the other hand, when the module X is used (step 301-11: Yes), the system 101 performs a search of the customer master database 202 with the customer ID acquired in step 301-9, and currently uses the module X. Information on the name of the customer, the name of the customer representative, and the email address of the customer representative are acquired (step 301-13).

  Furthermore, the system 100 sets the information set in the memory 13 in step 301-1, the information acquired in step 301-13, the name of module X, and the version number. Based on the above, data relating to the defective portion is added to the defect information database (no customization) 204 (step 301-15). In this example, the system 101 searches the customer introduction module database 203 for the module with the module ID “00002” and acquires the current use flag “0”. However, since the current use flag “0” means a module in which the module ID “00002” is not currently used, the processing is skipped to step 301-16.

  Next, the system 101 uses the module IDs “00002” and “00005” of the module X from the module master database 201 to obtain the module ID of the parent module of the module X and the module ID of the child module (Step 301- 16). In this process, when the module X has been acquired as the parent module in step 301-2 (in the case of the module acquired as the parent module ID of the module in which failure occurred in the module master database 201), the system 101 The parent module ID of the module X and the module ID of the child module of the module X that has not yet been checked for the influence of the defective part (the module ID of the module having the module ID of the module X as the parent module ID in the module master database 201) get.

  When the module X is acquired as a child module in step 301-2 (in the module master database 201, the module having the module ID of the module in which the failure has occurred in the parent module ID), the system 101 Get the module ID of the child module.

  In the example of FIG. 7, since the module with the module ID “00002” has been acquired as a child module in step 301-2, the system 101 acquires two child modules with the module ID “00003” and the module ID “00004”. To do. Similarly, since the module with the module ID “00005” has been acquired as a child module in step 301-2, the system 101 acquires the child module with the module ID “00006”.

  For the module acquired in step 301-16 (this is referred to as module Y), the system 101 performs an impact check (Y) for each acquired module Y, as in the previous processing. Execute (step 301-13). The module Y is a module identified by the module ID acquired in step 301-16. Further, the influence check (Y) indicates processing from step 301-4 to step 301-17 for the module Y. In step 301-5, the system 101 repeatedly executes the influence check (Y) until no defective portion is included in the module Y. If the defective portion is included in the module Y, the module Y is finally determined. Executes repeatedly until becomes the highest module (no more parent modules) and the lowest module (no more child modules). In the example of FIG. 7, the system 101 performs an influence check (Y) for three modules having a module ID “00003”, a module ID “00004”, and a module ID “00006”.

  For the module with the module ID “00003”, the system 101 searches and determines whether the program code of the defective portion is included (step 301-4, step 301-5). Since the module with the module ID “0003” in this embodiment does not include the program code of the defective part, the system 101 ends the process as it is.

  Further, the system 101 searches and determines whether or not the program code of the defective part is included for the module with the module ID “00004” (step 301-4, step 301-5). Since the module with the module ID “00004” in the present embodiment includes the program code of the defective part, the system 101 acquires the customization presence / absence flag “1” in step 301-6. As a result of the determination in step 301-7, the system 101 determines that the module with the module ID “00004” has been customized. The system 101 acquires the current use flag “1” and the customer ID “CUST04” for the module with the module ID “00004” (step 301-8). According to the information acquired here, since it can be determined that the module with the module ID “00004” is currently used, the system 101 determines that the customer name “D Corporation” in step 301-10 and step 301-12. , Customer contact name “DDD”, customer contact email address “DDD@D.co.jp”, responsible department / partner “P Inc.”, responsible department / partner contact name “YYY”, responsible department / partner email The address “YYY@Y.co.jp” is acquired. In step 301-14, the system 101 stores the delivery destination “P Corporation YYY” in the defect information database (customized) 205 and the department / partner email address “YYY@Y.co.jp” serving as the delivery destination address. ", Target module" Z_Class1.java ", target version number. Each information of “V1.0” and defect content is added.

  Subsequently, the system 101 acquires a parent module and a child module with the module ID “00004” (step 301-16). However, since the module with the module ID “00004” is the lowest module (in the parent-child relationship between the predetermined modules in the module master database 201), the process ends here. On the other hand, in the case of the module with the module ID “00006”, the system 101 searches and determines whether or not the defective portion program code is included in step 301-4, and includes the defective portion program code in step 301-5. Since it has been determined that it has not been performed, the processing is terminated.

  The system 101 performs the defect influence analysis process as described above by executing the software defect influence analysis program 301. By this process, the module affected by the defective part is specified, and the defect information databases 204 and 205 are created. Further, the software defect information distribution program 302 takes measures against the defective part from the software distribution relay server 102 (or the customer's software introduction site 103) of the internal department or the external partner company via the input screen 401. Version number of the module The location information (URL, etc.) of the countermeasured module and the inquiry destination are acquired. The information acquired here is stored in the defect information databases 204 and 205 by the system 101. Data input processing for such a database corresponds to database update processing via the Internet or an intranet that has been conventionally performed.

  Further, the software defect information distribution program 302 of the system 101 distributes the contents of the defect information databases 204 and 205 by an e-mail transmission process based on the delivery address of the defect information databases 204 and 205. This mail distribution process is realized by using commercially available mail distribution software that automatically distributes mail using database information as input. In the example of FIG. 7, the destination information “P Corporation YYY”, the target module “Z_Class1.java”, the target version number set in the defect information database (with customization) 205 by the software defect information distribution program 302. . For the data of “V1.0”, the version No. Information input of “V1.01”, countermeasure module location “www.abcd.co.jp”, and inquiry destination “Mr. A” is accepted from the input screen 401, and these information are sent to the mail address set in the destination address. On the other hand, it is automatically distributed (step 301-20).

According to the present invention, it is possible to automate and efficiently perform failure influence analysis between modules of multiple versions and failure influence analysis between customized modules. For this reason, it is possible to reduce the number of defect countermeasure steps of the software developer. In addition, since the period of software defect countermeasures is shortened, it becomes possible to provide software with a defect countermeasure version earlier to customers who have introduced software. As a result, the impact of defective software on customer operations can be improved. Reduction can be realized.
Therefore, it is possible to efficiently investigate the range of influence of defects occurring in the software module.

  As mentioned above, although embodiment of this invention was described concretely based on the embodiment, it is not limited to this and can be variously changed in the range which does not deviate from the summary.

It is a figure which shows the network structure containing the defect influence analysis apparatus of the software module of this embodiment. It is a figure which shows the data structure of the module master database in this embodiment. It is a figure which shows the data structure of the customer master database in this embodiment. It is a figure which shows the data structure of the customer introduction module database in this embodiment. It is a figure which shows the data structure of the defect information database in this embodiment. It is a figure which shows the example of the main flow in the defect influence analysis method of the software module of this embodiment. It is a conceptual diagram which shows the image of software defect influence analysis. It is a conceptual diagram which shows the image of the input screen of a software automatic delivery system.

Explanation of symbols

11 Program database 12 Program 13 Memory 14 CPU
15 I / O interface 16 Communication means 17 I / O unit 101 Software module failure effect analysis device (automatic software distribution system)
102 Software Distribution Relay Server 103 of Internal Department and External Partner Company 103 Software Installation Site 110 Defective Location Identification Unit 111 Parent / Child Version Extraction Unit 112 Defective Location Remaining Check Unit 113 Output Processing Unit 114 Defective Notification Unit 115 Notification Destination Selection Unit 140 Network 201 Module master database 202 Customer master database 203 Customer introduction module database 204 Defect information database (no customization)
205 Defect information database (with customization)
301 Software Defect Influence Analysis Program 302 Software Defect Information Distribution Program 303 Module Information Registration Program 401 Software Automatic Distribution System Input Screen 501 System Control Unit of Software Automatic Distribution System

Claims (5)

A device that analyzes the effects of defects on software modules,
A defect location identifying section for identifying a defect location of the module in which the failure has occurred;
The module master database that stores information on the parent-child relationship between modules based on the version is referenced, and the version of the parent module that is the basis for creating the failure occurrence module and the version that is derived from the failure occurrence module A parent-child version extraction unit for extracting child modules;
A defective part remaining check part for confirming that the defective part specified by the defective part specifying part remains in the version of the parent or child module extracted by the parent-child version extracting unit;
An output processing unit that outputs the result of the remaining defect check to an output interface;
A software module failure effect analyzer. In claim 1,
With reference to the customer master database storing the customer information of each version of the module, extract the customer information of the version of the module for which the defective part remains confirmed by the defective part remaining check unit, and having a defect notification unit that performs a notification of defective portions remaining to the relevant delivery destination customer on the basis of the delivery destination customer information, failure effect analyzer software modules. In claim 2,
Refer to the customer master database that stores information about the customization of each module in the module master database and the relationship information between the delivery customer and the company in charge of the customization. of a notification with a notification destination selection unit that performs a selection of either of the notification destination delivery destination customer or customize responsible company, failure impact analysis apparatus of the software module. A method of analyzing the influence of a defect occurring in a software module by a computer, wherein the computer
Identify the defective part of the defective module,
The module master database that stores information on the parent-child relationship between modules based on the version is referenced, and the version of the parent module that is the basis for creating the failure occurrence module and the version that is derived from the failure occurrence module Extract child modules and
Confirm that the defective part remains in the version of the parent or child module,
A software module failure effect analysis method for outputting a result of the residual defect remaining confirmation to an output interface. A program for causing a computer to execute a method for analyzing a defect effect generated in a software module,
Identifying the defective part of the defective module;
The module master database that stores information on the parent-child relationship between modules based on the version is referenced, and the version of the parent module that is the basis for creating the failure occurrence module and the version that is derived from the failure occurrence module Extracting child modules; and
Confirming that the defective part identified in the step remains in the version of the parent or child module;
Outputting a result of the remaining part remaining confirmation to an output interface;
A software module failure effect analysis program for causing the computer to execute .