Defect information management system and defect information management method

Abstract

To extract relevant malfunction information.SOLUTION: The malfunction information management system includes an arithmetic device for executing a program and a storage device accessible to the arithmetic device. The storage device stores a software configuration information database for storing software configuration information related to software and a malfunction information database for storing malfunction information related to the software. The arithmetic device of the malfunction information management system includes a correspondence determining unit that compares a plurality of software configuration information with a plurality of malfunction information, determines a relation between each of the plurality of malfunction information and the software, and distributes the malfunction information related to the software.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The technical field relates to a defect information management system and a defect information management method for distributing defect information. [Background Art]

[0002] As background art in the present technical field, there is the following prior art. Patent Document 1 discloses an automatic software distribution management system that distributes software via a network system, which is aimed at solving the problem of "eliminating the need for environmental checks and prerequisite judgments by users at software distribution destinations, enabling automatic distribution of software from a distribution source to a distribution destination, and making installation operations at the distribution destination easy and convenient". As the solution to the problem, "in the automatic software distribution management system, a distribution destination comprises information collection means for collecting information on the hardware environment and / or software environment of said distribution destination and notifying the distribution source of the collected information; the distribution source comprises conformity check means for judging whether the use conditions of the software to be distributed to the distribution destination conform to the environment of the distribution destination based on the information notified from the information collection means, and distribution means for distributing the software to the distribution destination when the conformity check means judges that the software conforms to the environment, thereby enabling automatic distribution of software" (see the abstract of Patent Document 1).

[0003] Patent Document 2 addresses the objective of "providing a defect identification device, a defect identification method, and a defect identification program capable of identifying defects that are presumed to be highly likely to occur," and discloses a defect identification device as a solution, comprising: an input unit for inputting server device configuration information, resource usage information, and log information; a storage unit for storing at least one defect information including the defect details of a software defect and multiple occurrence conditions; a determination unit that determines whether each of the multiple occurrence conditions is met for at least one defect information based on the configuration information, resource usage information, and log information; an identification unit that identifies software defect information that is predicted to occur based on the determination result; and an output unit that outputs a first warning including the defect details included in the identified defect information (see abstract of Patent Document 2). [Prior art documents] [Patent Documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 10-301760 [Patent Document 2] Japanese Patent Publication No. 2021-128665 [Overview of the project] [Problems that the invention aims to solve]

[0005] In the software automatic distribution management system described in Patent Document 1, information on past defects is searched from a defect condition file during software distribution to determine if a known defect will occur. If a defect occurs, a warning is sent to the software recipient via email or other means. However, tracking whether the impact of the defect information has actually been confirmed and whether the defect has been repaired is not considered.

[0006] The malfunction identification device described in Patent Document 2 identifies and warns about affected malfunction information based on the configuration information, resource usage information, and log information of the server device that is the target of the malfunction information impact check. However, it is not possible to identify affected malfunction information unless the software is run in advance and logs are acquired. [Means for solving the problem]

[0007] A representative example of the invention disclosed in this application is as follows: a defect information management system comprising a computing device that executes a program and a storage device accessible by the computing device, the storage device being A software configuration information database stores software configuration information related to the software, including the type of software component, vendor name, function, and version; and a defect information database stores defect information related to the software, including the type of software component, vendor name, function, and version. The system stores the above, and the fault information management system has the computing device compare the plurality of software configuration information and the plurality of fault information, The type, vendor name, function, and version of the software components of multiple software configuration information are compared with the type, vendor name, function, and version of the software components of multiple defect information, and the relationship between each of the multiple defect information and the software is determined when the type, vendor name, function, and version of the software components match. It is characterized by having a determination unit that distributes defect information related to the aforementioned software. [Effects of the Invention]

[0008] According to one aspect of the present invention, relevant defect information can be extracted without obtaining logs of software execution. Problems, configurations, and effects other than those described above will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0009] [Figure 1] This diagram shows the configuration of the defect information management system in Example 1. [Figure 2] This diagram shows the relationship between defect information and impact confirmation request information for Example 1. [Figure 3] This diagram shows the configuration of the defect information database in Example 1. [Figure 4] This diagram shows the configuration of the software configuration information for Example 1. [Figure 5] This diagram shows the structure of the information requested to confirm the impact of Example 1. [Figure 6] This is a flowchart of the defect information distribution process using the defect information management device of Example 1. [Figure 7] This figure shows an example of how to determine whether a defect information in Example 1 is applicable. [Modes for carrying out the invention]

[0010] The following describes an embodiment in detail using drawings.

[0011] Figure 1 shows the configuration of the defect information management system in Example 1.

[0012] The defect information management system includes a defect information distribution system 106 and process management systems 101a to 101n.

[0013] In this embodiment, the applicability determination unit 107 of the defect information distribution system 106 generates impact confirmation request information 110a based on the defect information 108 to be distributed and the software configuration information 103, distributes the defect information, and enables support for confirming the impact of the defect indicated in the defect information on software under development or released software without running the software. The software handled by the defect information distribution system 106 and the process management systems 101a to 101n is, for example, an electronic control unit (in-vehicle ECU) or is executed on another computer.

[0014] Defect information refers to information regarding defects in third-party vendor products (hardware, software, development tools) and in-house software used in software development. The structure of the defect information will be described later with reference to Figure 3. In this specification, third-party vendor products (hardware, software, development tools) and in-house software used in software development will be simply referred to as software components.

[0015] The process management systems 101a to 101n shown in FIG. 1 are systems that provide a function of supporting management of the development process of software to which defect information is distributed, and each includes definition of information on software components used in software development, definition of work tasks occurring in software development, progress management, and the like. In the present embodiment, the process management systems 101a to 101n are provided corresponding to software development projects a to n respectively, and impact confirmation support can be provided for a plurality of process management systems 101a to 101n. Hereinafter, the process management system 101a will be described as an example.

[0016] The software configuration information database 102 shown in FIG. 1 is a database system provided in the process management system 101a and manages software configuration information. The software configuration information defines information related to software components used during software development. Components of the software configuration information will be described later with reference to FIG. 4. Software configuration information 103a to 103c are examples of software configuration information created when developing a new version of software.

[0017] The defect information database 104 shown in FIG. 1 is a database system provided in a defect information distribution system 106 and manages defect information. Defect information 105a to 105c are, as examples of defect information stored in the defect information database 104, information related to defects necessary for generating impact confirmation request information.

[0018] A non-applicability determination unit 107 of a defect information distribution system 106 monitors a defect information database 104 and a software configuration information database 102 at a predetermined timing (for example, at predetermined time intervals). When the non-applicability determination unit 107 receives a defect information distribution request from a member of a software development project, the non-applicability determination unit 107 generates impact confirmation request information 110a as a work task managed by a process management unit 109 based on defect information 108 to be distributed referenced from the defect information database 104 and software configuration information 103 referenced from the software configuration information database 102, and distributes the generated impact confirmation request information 110a as defect information. The components of the impact confirmation request information 110a will be described later with reference to FIG. 5.

[0019] First, the non-applicability determination unit 107 of the defect information distribution system 106 extracts one piece of defect information 108 to be distributed from defect information 105a to 105c stored in the defect information database 104, and acquires all software configuration information 103 stored in the software configuration information database 102.

[0020] Next, the non-applicability determination unit 107 performs non-applicability determination on all software configuration information 105a to 105c stored in the software configuration information database 102. If any component matches between the defect information 108 to be distributed and the software configuration information 103, bidirectional related information is added between the defect information distribution system 106 and a process management system 101a, and impact confirmation request information 110a is generated. The detailed method of non-applicability determination will be described later with reference to FIG. 7. This enables efficient acquisition of defect information that affects software under development or already released.

[0021] The malfunction information distribution system 106 is composed of a computer having a processor, memory, auxiliary storage device, and communication interface. The processor is an arithmetic unit that executes programs stored in memory. The functions provided by the malfunction information distribution system 106 are realized by the processor executing various programs. Note that some of the processing performed by the processor when executing programs may be performed by other arithmetic units (e.g., hardware such as ASICs and FPGAs). The memory includes ROM, which is a non-volatile memory element, and RAM, which is a volatile memory device. ROM stores immutable programs (e.g., BIOS). RAM is a high-speed, volatile memory device such as DRAM (Dynamic Random Access Memory) and temporarily stores programs executed by the processor and data used when executing programs. The auxiliary storage device is a large-capacity, non-volatile memory device such as a magnetic memory device and stores programs executed by the processor and data used by the processor when executing programs. The communication interface is a network interface device that controls communication with other devices according to a predetermined protocol.

[0022] The program executed by the processor is provided to the malfunction information distribution system 106 via removable media (such as a CD-ROM or flash memory) or a network, and is stored in a non-volatile auxiliary storage device, which is a non-temporary storage medium. For this reason, the malfunction information distribution system 106 should have an interface for reading data from the removable media.

[0023] The defect information distribution system 106 is a computer system that operates on a single physical computer, or on one or more logically or physically configured computers, and may operate on a virtual computer built on multiple physical computer resources. For example, the matching determination unit 107 and the defect information database 104 may operate on separate physical or logical computers, or multiple units may be combined and operate on a single physical or logical computer.

[0024] Figure 7 shows an example of how to determine whether a defect information is applicable. It is determined whether the configuration information of the extracted defect information A701 to be distributed matches the components of software configuration information A702, software configuration information B703, and software configuration information C704. In this embodiment, as an example, the versions of the software components are increased by 1 each time, from 1, 2, 3, ..., n, and when written as 1 to 5, versions 1 to 5 are the target versions. Also, a regular expression (*) is used for the vendor name of the software component in the defect information A701. All components match exactly with software configuration information A702, and it is determined that the components match. Also, all components except the vendor name of the software component match exactly with software configuration information B703, and the vendor name of the software component matches using the regular expression, and it is determined that the components match. On the other hand, the version of the software component does not match with software configuration information C704, and it is determined that the components do not match.

[0025] Figure 2 shows the relationship between defect information 108 and impact confirmation request information 110a to 110n. For each piece of software that requests impact confirmation for a single defect information 108, impact confirmation request information is generated. Furthermore, bidirectional relationship information is maintained between the defect information 108 and the impact confirmation request information 110a to 110n, respectively, between the defect information distribution system 106 and the process management system 101a. This makes it possible to confirm the impact of the defect information and to track whether repairs have been made bidirectionally from the defect information database 104 and the process management system 101a.

[0026] Figure 3 shows the configuration of the defect information database 104 and the defect information 302a to 302n stored in the defect information database 104 in this embodiment. There may be multiple defect information entries 302 (for example, defect information entries 302a to 302n). In this embodiment, defect information 302a will be described as an example. Defect information 302a defines the following components: software component type 303, software component vendor name 304, software component function 305, software component version 306, defect identifier 307, defect description 308, defect workaround 309, and defect impact confirmation flow 310. Components 303 to 309 of defect information 302a are stored in the defect information database 104 when a defect occurs. Depending on the software component type 303, the software component function 305 and software component version 306 may not be included. In addition, defect information 302 may include components other than those described above.

[0027] The defect identifier 307 is, for example, a unique ID issued by the defect provider. The defect impact confirmation flow 310 is generated based on the defect description 308 and the defect workaround 309 to standardize the impact confirmation of software defect information and to confirm the impact of the defect information regardless of the skills of the software development project members. The defect impact confirmation flow 310 includes one or more logical expressions or natural language 311 that indicate the conditions under which the defect applies, and is created by a software development expert.

[0028] Figure 4 shows the configuration of the software configuration information 401 in this embodiment. The software configuration information 401 defines the following components: the software name 402, software release version information 403, software component type 404, software component vendor name 405, software component function 406, and software component version 407, and describes the information of the software component used during the development of the relevant software. The software component function 406 and software component version 407 may not be described depending on the software component type 404. In addition, the software configuration information 401 may include components other than those described above. The software configuration information 401 is generated when new software development starts and when a new version of the software is developed.

[0029] The software name 402 is an identifier used to uniquely identify multiple software programs.

[0030] Software release version information 403 is an identifier used to request impact assessment for all versions of software that is under development or has been completed.

[0031] Figure 5 shows the configuration of the impact confirmation request information 501 in this embodiment. The impact confirmation request information 501 defines the following components: a defect identifier 502, a defect impact confirmation flow 503, and a confirmation result 504.

[0032] The defect identifier 502 is obtained and recorded when the impact confirmation request information is generated, by acquiring the defect identifier 307 from the defect information 108 which is the basis for the impact confirmation request information 501.

[0033] The defect impact confirmation flow 503 is recorded by obtaining the defect impact confirmation flow 310 of the defect information 108, which is the basis for the impact confirmation request information 501, when the impact confirmation request information is generated.

[0034] Verification result 504 is recorded when the impact of a software defect is checked, etc.

[0035] Referring to Figure 6, the process of distributing defect information using the defect information management device in this embodiment will be described.

[0036] S601: The applicability determination unit 107 of the defect information distribution system 106 references one defect information item 108 to be distributed from the defect information 105a to 105c stored in the defect information database 104. If there is no defect information to reference at this time, the defect information is not distributed.

[0037] S602: The defect information distribution system 106 refers to the software configuration information 103 stored in the software configuration information database 102 of the process management system 101a. If there is no software configuration information to refer to, the defect information is not distributed.

[0038] S603: Determine whether the components of the defect information 108 referenced in S601 and the software configuration information 103 referenced in S602 match. For example, determine whether the type of software component, the vendor name of the software component, the function of the software component, and the version of the software component included in the defect information 108 match the type of software component, the vendor name of the software component, the function of the software component, and the version of the software component included in the software configuration information 103. In this case, the descriptions of the components of the defect information and software configuration information may be expressed using regular expressions, etc., and the determination may be made by partial matching.

[0039] S604-S605: The defect identifier and defect impact confirmation flow included in the defect information 108 referenced in S601 are described as components of the impact confirmation request information 110a. Furthermore, the impact confirmation request information 110a is generated by adding bidirectional related information between the defect information distribution system 106 and the process management system 101a, and the defect information is distributed. Then, the impact confirmation request information is registered in the process management system 101a. This series of processes is performed for all defect information stored in the defect information database 104.

[0040] This embodiment allows for the efficient extraction of relevant defect information without the need to obtain logs of software execution. Furthermore, the impact of the defect and whether it has been repaired can be tracked bidirectionally from either the defect information database 104 or the process management system 101a.

[0041] As described above, according to the embodiment of the present invention, relevant defect information can be efficiently extracted without obtaining logs of software execution. Furthermore, whether the impact of the defect information has been confirmed and repaired can be tracked from both the defect information database 104 and the process management system 101.

[0042] It should be noted that the present invention is not limited to the embodiments described above, but includes various modifications and equivalent configurations within the spirit of the attached claims. For example, the embodiments described above are described in detail for the purpose of clearly illustrating the present invention, and the present invention is not necessarily limited to having all the described configurations. Furthermore, some of the configurations of one embodiment may be replaced with those of another embodiment. Furthermore, configurations of other embodiments may be added to the configuration of one embodiment. Furthermore, some of the configurations of each embodiment may be added, deleted, or replaced with those of other embodiments.

[0043] Furthermore, each of the aforementioned configurations, functions, processing units, and processing means may be implemented in hardware, for example, by designing them as integrated circuits, or they may be implemented in software by having a processor interpret and execute programs that realize each function.

[0044] Information such as programs, tables, and files that implement each function can be stored in memory, hard disks, SSDs (Solid State Drives), or other storage media such as IC cards, SD cards, and DVDs.

[0045] Furthermore, the control lines and information lines shown are those deemed necessary for explanatory purposes and do not necessarily represent all control lines and information lines required for implementation. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]

[0046] 101a~101n Process Management System 102 Software Configuration Information Database 103a~103c Software Configuration Information 104 Defect Information Database 105a~105c Bug Information 106. Bug Information Distribution System 107 Applicability determination section 108 Information on defects in the distribution target 109 Process Management Department 110a~110c Impact Confirmation Request Information Bug information for 302a~302n 401 Software Configuration Information 501 Request for Impact Assessment Information

Claims

1. This is a defect information management system, The system includes a computing unit that executes a program and a storage device that the computing unit can access. The storage device stores a software configuration information database that stores software configuration information relating to the software, including the type of software component, vendor name, function, and version, and a defect information database that stores defect information relating to the software, including the type of software component, vendor name, function, and version. The defect information management system is characterized in that the computing device compares the type, vendor name, function, and version of software components of a plurality of software configuration information with the type, vendor name, function, and version of software components of a plurality of defect information, determines the relationship between each of the plurality of defect information and the software in which the type, vendor name, function, and version of software components match, and distributes the defect information that is related to the software.

2. A defect information management system according to claim 1, The defect information management system is characterized in that the matching determination unit refers to software configuration information stored in the software configuration information database to identify the software to which the defect information will be distributed.

3. A defect information management system according to claim 1, The defect information management system is characterized in that the corresponding determination unit identifies defect information to be distributed by referring to defect information stored in the defect information database.

4. A defect information management system according to claim 2, The said determination unit is, When creating new software, or when modifying existing software, the new software configuration information is added to the software configuration information database. A defect information management system characterized by determining the relationship between each of the multiple defect information items and the software based on the newly added software configuration information.

5. A defect information management system according to claim 1, The defect information management system is characterized in that the matching unit, when adding new defect information to the defect information database and when updating existing defect information, refers to the defect information database to determine the relationship between each of the multiple defect pieces of information and the software.

6. A defect information management system according to claim 1, The aforementioned software configuration information and the aforementioned defect information are organized into separate items. The defect information management system is characterized in that the matching determination unit compares the software configuration information and the defect information for each item.

7. A defect information management system according to claim 1, The aforementioned software configuration information and the aforementioned defect information are organized into separate items. The defect information management system is characterized in that the matching determination unit can determine whether a part of the software configuration information matches a part of the defect information for each item.

8. A defect information management system according to claim 1, A defect information management system characterized in that the defect information is associated with impact confirmation request information, which is referenced when confirming the impact of the defect.

9. A defect information management system according to claim 8, The aforementioned impact confirmation request information includes a defect impact confirmation flow that proceduralizes the confirmation of the impact of software defect information, and is characterized by this defect information management system.

10. A defect information management method performed by a defect information management system, The aforementioned malfunction information management system is comprised of a computer having an arithmetic unit for executing programs and a storage device accessible by the arithmetic unit. The storage device stores a software configuration information database that stores software configuration information relating to the software, including the type of software component, vendor name, function, and version, and a defect information database that stores defect information relating to the software, including the type of software component, vendor name, function, and version. The aforementioned defect information management method is: A defect information management method characterized in that the computing device compares the type, vendor name, function, and version of software components of a plurality of software configuration information with the type, vendor name, function, and version of software components of a plurality of defect information, determines the relationship between each of the plurality of defect information and the software in which the type, vendor name, function, and version of software components match, and distributes the defect information related to the software.

Images