JP6016613B2 - Software reliability evaluation apparatus, software reliability evaluation method, and program - Google Patents

Description

  The present invention relates to a software reliability evaluation apparatus, a software reliability evaluation method, and a program.

  As a method of evaluating the reliability of software, there is a method of estimating the number of remaining bugs from a Gompertz curve model or a logistic curve model and a bug occurrence history and evaluating the software reliability. Also, a method for estimating the parameters of these curve models (see, for example, Patent Document 1), and a method for correcting the reliability growth curve of software by the Gompertz curve model by inputting the bug discovery efficiency together with the bug occurrence history ( For example, a technique for improving the accuracy of software reliability prediction is known (see Patent Document 2).

JP 2000-122860 A JP 2008-171307 A

  By the way, bugs are not distributed uniformly in the source code but tend to be unevenly distributed. Therefore, in the conventional reliability evaluation method, since the uneven distribution of bugs is not taken into consideration, the accuracy of the calculated reliability is insufficient.

  The present invention has been made under the above circumstances, and an object thereof is to provide a software reliability evaluation apparatus, method, and program capable of evaluating the reliability of software with higher accuracy.

In order to achieve the above object, a software reliability evaluation apparatus according to the present invention provides:
A software reliability evaluation apparatus for evaluating the quality of software composed of a plurality of modules,
A development condition storage unit that stores information indicating a module and development conditions that can affect the quality of the module at the time of development of the module in association with each other;
A division setting storage unit that stores information indicating development conditions and a division granularity that represents the size of a division unit when dividing a plurality of elements that constitute the development conditions;
A bug history storage unit representing a module and the number of bugs in the module;
A division condition determination unit that acquires information indicating a development condition that is a condition to be divided and a division granularity of the development condition;
From the development condition storage unit, the module corresponding to the development condition acquired by the division condition determination unit is specified, and the division granularity stored in the division setting storage unit and the division granularity acquired by the division condition determination unit A dividing unit for dividing the software into partial source code,
For each partial source code generated by the dividing unit, based on the number of bugs stored in the bug history storage unit, the partial bug density representing the percentage of bugs in the entire partial source code, and the percentage of bugs in the entire software An overall bug density representing, a bug density calculation unit for calculating,
Based on the partial bug density and the total bug density calculated by the bug density calculation unit, it is determined whether the partial bug density is biased with respect to the total bug density, and the partial bug density determined to be biased is determined. An evaluation unit that outputs information representing the corresponding partial source code;
It is characterized by providing.

  According to the present invention, the reliability of software can be evaluated with higher accuracy.

It is a block diagram which shows the hardware constitutions of the software reliability evaluation apparatus which concerns on embodiment of this invention. It is a figure which shows an example of module position division | segmentation setting information. It is a figure which shows an example of developer division | segmentation setting information. It is a figure which shows an example of development condition DB. It is a figure which shows an example of bug log | history DB. It is a block diagram which shows the function structure of the software reliability evaluation apparatus which concerns on embodiment of this invention. It is a flowchart which shows an example of the flow of a reliability evaluation process. It is a flowchart which shows an example of the flow of a division condition adjustment process. It is a flowchart which shows an example of the flow of a development time condition adjustment process. It is a flowchart which shows an example of the flow of a module position condition adjustment process.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

  FIG. 1 is a schematic block diagram showing a hardware configuration of a software reliability apparatus according to an embodiment of the present invention. The software reliability evaluation apparatus 1 is an apparatus for evaluating the reliability of software composed of a plurality of modules, and as shown in FIG. ) 130, a control unit 140, a ROM (Read Only Memory) 150, a RAM (Random Access Memory) 160, and a storage unit 170.

  The input unit 110 is connected to an input device 2 such as a mouse or a keyboard for the user to operate the software reliability evaluation device 1 and accepts various types of information input by the user.

  The output unit 120 is connected to the output device 3 such as a liquid crystal display. The output unit 120 outputs various information output by the control unit 140.

  The external I / F unit 130 is connected to a drive device (not shown) or the like for reading from and writing to a removable disk such as a CD (Compact Disc). Further, it may be connected to a device for connecting to an external network (for example, the Internet, a LAN (Local Area Network), etc.) or a printer for printing information generated by the control unit 140.

  The control unit 140 includes, for example, a CPU (Central Processing Unit), and performs overall control of the software reliability evaluation apparatus 1. For example, the control unit 140 executes a reliability evaluation process. Details of the reliability evaluation process will be described later.

  The ROM 150 is a non-volatile memory that stores a program and the like for the control unit 140 to control the entire software reliability evaluation apparatus 1. For example, the ROM 150 stores a program for executing the reliability evaluation process.

  The RAM 160 is a volatile memory for temporarily storing information generated by the control unit 140 and data necessary for generating the information.

  The storage unit 170 includes a storage device such as a hard disk drive. Specifically, the storage unit 170 stores a division setting DB (database) 171, a development condition DB 172, and a bug history DB 173.

  The division setting DB 171 stores division setting information indicating the division granularity of the software under the development condition for each development condition that can affect the quality of the module at the time of module development. Here, the division granularity represents the size of a division unit when dividing a plurality of elements constituting the development condition. In the present embodiment, a case where the module position, the developer, and the development time are used as an example of a development condition that can affect the quality of the module during the development of the module will be described.

  The module position represents a position in a hierarchical structure (source tree) of a plurality of modules constituting software to be evaluated. The higher the module position, the wider the range of influences of bugs occurring in the module and the presence or absence of usage changes during development, which may affect the quality of software. The division setting DB 171 stores module position division setting information 171a as division setting information using the module position as a development condition.

  FIG. 2 shows an example of the module position division setting information 171a. As shown in FIG. 2, the module position division setting information represents the hierarchical structure of modules and the division granularity thereof. Specifically, the module position division setting information illustrated in FIG. 2 has three division granularities of “large module”, “medium module”, and “small module” according to the module hierarchy.

  Developer represents the person who developed the module. Depending on the skill level of the developer, the quality of the module developed by the developer can be affected. The division setting DB 171 stores developer division setting information 171b as division setting information with a developer as a development condition.

  FIG. 3 shows an example of the developer division setting information 171b. As shown in FIG. 3, the developer division setting information represents a developer group configuration and its division criteria. Specifically, the developer division setting information illustrated in FIG. 3 has two division granularities of “developer large” and “developer small”.

  The development time represents the time when the module was developed. Since the developer's fatigue level and mental margin change depending on when the development period is, for example, the final stage or the initial stage of development, the development period can affect the quality of the software. When the development time is set as the development condition, the division granularity may be a predetermined period preset by the user or the like in addition to a general time break such as month or week.

  The development condition DB 172 stores information representing the development condition of the module for each of a plurality of modules constituting the software. FIG. 4 shows an example of data stored in the development condition DB 172. As shown in FIG. 4, the development condition DB 172 specifically stores information representing the developer of the module and the development time of the module for each module.

  The bug history DB 173 stores information representing the number of bugs for each of a plurality of modules constituting the software. FIG. 5 shows an example of data stored in the bug history DB 173. The number of bugs is acquired as, for example, the number of test items for which normal output is not obtained among the test items performed on the module.

  Next, a functional configuration of the control unit 140 of the software reliability evaluation apparatus 1 will be described. As illustrated in FIG. 6, the control unit 140 functions as a division condition determination unit 141, a division unit 142, a bug density calculation unit 143, and an evaluation unit 144.

  The division condition determination unit 141 determines a division condition for dividing the software to be evaluated. Specifically, the division condition determination unit 141 acquires information representing the development conditions and the division granularity from the user via the input unit 110. In addition, the division condition determination unit 141 may determine to divide all combinations of the development conditions and the division granularity when the development condition and the information indicating the division granularity are not acquired from the user.

  In addition, when the evaluation unit 144 determines that the partial bug density is biased, the partitioning condition determination unit 141 determines a partitioning condition for re-partitioning the partial source code determined to be biased. .

  The dividing unit 142 divides the software to be evaluated according to the dividing condition determined by the dividing condition determining unit 141, and generates partial source code information. The partial source code information is information representing a module belonging to each divided part when the software to be evaluated is divided according to the division condition.

  The bug density calculation unit 143 includes an overall bug density that represents the ratio of bugs to the entire software to be evaluated, and a partial bug density that represents the ratio of bugs to the entire module represented by each partial source code information generated by the division unit 142. , Is calculated.

Specifically, the total bug density Da is defined as follows, where Ka and Ua are the number of known bugs and the number of unknown bugs in the entire software to be evaluated, respectively, and Sa is the number of development steps of the entire software to be evaluated. It is calculated as follows.
Da = (Ka + Ua) / Sa (1)

  In the above equation (1), the number of known bugs Ka can be calculated from, for example, the bug history DB 173 as the total number of bugs of all the modules constituting the software to be evaluated. The number of unknown bugs Ua can be calculated by, for example, a known method for predicting the number of bugs such as a Gompertz curve model or a logistic curve model. Further, the development step number Sa can be calculated from the total number of steps of all modules constituting the software to be evaluated.

The partial bug density Dp is the number of known bugs and the number of unknown bugs in the entire module represented by each partial source code information generated by the dividing unit 142, respectively, Kp and Up, and the number of development steps of the entire module. Sp is calculated as follows.
Dp = (Kp + Up) / Sp (2)

  In the above equation (2), the number of known bugs Kp can be calculated from, for example, the bug history DB 173 as the total number of bugs of the entire module represented by each partial source code information. Further, the number of unknown bugs Up can be calculated by, for example, a known method for predicting the number of bugs such as a Gompertz curve model or a logistic curve model. Further, the development step number Sp can be calculated from the total number of steps of the entire module represented by each partial source code information generated by the dividing unit 142.

  The evaluation unit 144 determines whether the partial bug density is biased with respect to the total bug density based on the total bug density and the partial bug density calculated by the bug density calculation unit 143. Specifically, the evaluation unit 144 determines, for each partial bug density calculated by the bug density calculation unit 143, whether or not the partial bug density is greater than a predetermined value by a predetermined value or more. It is determined that the partial bug density is biased.

  Next, the flow of reliability evaluation processing executed by the software reliability evaluation apparatus 1 will be described. FIG. 7 is a flowchart showing an example of the flow of reliability evaluation processing executed by the software reliability evaluation apparatus 1. The reliability evaluation process illustrated in FIG. 7 is started, for example, when an operation indicating that the execution of the reliability evaluation process is started is input by the user via the input device 2. Further, the data stored in the division setting DB 171, the development condition DB 172, and the bug history DB 173 is extracted in advance from the software to be evaluated or input by the user via the input device 2. It is assumed that it is stored in the storage unit 170.

  First, the bug density calculation unit 143 calculates the overall bug density (step S11). Specifically, the bug density calculation unit 143 calculates the overall bug density for the entire software to be evaluated using equation (1).

  Next, the division condition determination unit 141 acquires development conditions and information indicating the division granularity as a division condition from the user via the input unit 110 (step S12).

  Next, the dividing unit 142 generates partial source code information based on the development conditions acquired in step S12 and the division granularity (step S13).

  The generation of the partial source code information will be specifically described below. For example, in step S12, it is assumed that the division condition determination unit 141 acquires “module position” as the development condition and “in module” as the division granularity. In this case, the division unit 142 refers to the module position division setting information 171a stored in the division setting DB 171 and divides the software to be evaluated with the division granularity corresponding to the module to configure the partial source code. Partial source code information representing all modules to be generated is generated.

  Specifically, in the module position division setting information 171a shown in FIG. 2, the dividing unit 142 divides the module as the division granularity, so that “AAa” and “AAa” which are lower modules of “AA” and Two pieces of partial source code information including partial source code information representing “AAb” and partial source code information representing “ABa”, “ABb”, and “ABc”, which are lower modules of “AB” and “AB” Is generated.

  In addition, when the division condition determination unit 141 acquires a plurality of development conditions and the division granularity of each development condition, the division unit 142 divides the evaluation target software according to the combination of the development conditions and the division granularity. And partial source code information is generated.

  For example, in step S12, the division condition determination unit 141 acquires “module position” as the development condition, “in module” as the division granularity, “development time” as the development condition, and “month” as the division granularity. Suppose that In this case, the division unit 141 refers to the module position division setting information 171a stored in the division setting DB 171 and divides the software to be evaluated with the division granularity corresponding to the module. Further, the dividing unit 142 refers to the development condition DB 172 for each divided partial source code, and specifies the development time of the partial source code. Then, the dividing unit 142 generates partial source code information by further dividing the partial source code for each month of the specified development period.

  Next, the bug density calculation unit 143 calculates a partial bug density for each partial source code information generated in step S13 (step S14). Specifically, the bug density calculation unit 143 calculates a partial bug density for each partial source code information generated in step S13, using the equation (2), for the entire module represented by the partial source code information.

  Next, the evaluation unit 144 determines, for each partial source code information, whether or not the partial bug density calculated in step S14 is biased with respect to the overall bug density calculated in step S11 (step S15). ). Specifically, the evaluation unit 144 determines that the partial bug density is biased when the partial bug density is a predetermined value or more than the entire bug density.

  If the evaluation unit 144 determines that the partial bug density is biased (step S15; Yes), the evaluation unit 144 executes a division condition adjustment process (step S16). If the evaluation unit 144 determines that the partial bug density is not biased (step S15; No), the process proceeds to step S17.

  FIG. 8 is a flowchart illustrating an example of the flow of the division condition adjustment process executed by the software reliability evaluation apparatus 1.

  First, the division condition determining unit 141 determines whether or not the development condition is included in the development conditions acquired in step S12 of FIG. 7 (step S21).

  When it is determined that the development time is included (step S21; Yes), the development time condition adjustment process is executed (step S22). If it is determined that the development time is not included (step S21; No), the process proceeds to step S24.

  FIG. 9 is a flowchart illustrating an example of the flow of development time condition adjustment processing executed by the software reliability evaluation apparatus 1. In this development time condition adjustment processing, the partial bug density is calculated again by shifting the period corresponding to the division granularity of the development time back and forth for the part determined to be uneven in the partial bug density in step S15 of FIG. As a result, the time when the bug density is high can be identified more accurately.

  First, the division condition determination unit 141 sets, as an initial period, a period corresponding to the division granularity of the development time for the partial source code information determined to have partial bug density bias in step S15 of FIG. S31). Also, n representing the number of days shifted from the initial period is set to 0.

  The division condition determining unit 141 increments n by 1 (step S32).

  Next, the division condition determination unit 141 determines whether n is smaller than the division granularity at the development time acquired in step S12 (step S33).

  When it is determined that n is smaller than the division granularity (step S33; Yes), the division unit 142 refers to the development condition DB 172 and refers to the development condition DB 172. The information is generated, and the bug density calculation unit 143 calculates a partial bug density for the partial module information (step S34).

  The dividing unit 142 refers to the development condition DB 172, generates partial module information for a module whose development time is within a period shifted n days from the initial period, and the bug density calculating unit 143 generates the partial module information. The partial bug density is calculated for (Step S35). Then, the process returns to step S32.

  When it is determined that n is greater than or equal to the division granularity (step S33; No), the evaluation unit 144 sets the period with the highest bug density as the high bug density period among the partial bug densities calculated in step S34 and step S35. Store (step S36). Then, the process proceeds to step S23 in FIG.

  Returning to FIG. 8, when it is determined that the development condition does not include the development time (step S21; No), the division condition determination unit 141 determines whether the development condition acquired in step S12 of FIG. 7 includes the module position. Is determined (step S23).

  When it is determined that the development condition includes the module position (step S23; Yes), the process proceeds to the module position condition adjustment process of FIG. 10 (step S24).

  FIG. 10 is a flowchart illustrating an example of a module position condition adjustment process executed by the software reliability evaluation apparatus 1. In this module position condition adjustment processing, a module having a high bug density is obtained by calculating a partial bug density again for the adjacent module for the part determined to have a bias in the partial bug density in step S15 of FIG. Further, it can be specified with high accuracy. In the present embodiment, the adjacent module is specifically a module corresponding to a lower level in the module hierarchical structure. However, adjacent modules are not limited to this, and for example, parents and siblings in a module hierarchical structure may be considered as adjacent modules.

  First, the division condition determining unit 141 determines the development condition as the module position and the division granularity obtained in step S12 of FIG. 7 as the division condition (step S41).

  Next, the dividing unit 142 generates partial source code information based on the dividing condition determined in step S41 as in step S13 of FIG. 7 (step S42).

  Next, the bug density calculation unit 143 calculates a partial bug density for each partial source code information generated in step S42, similarly to step S14 in FIG. 7 (step S43).

  Next, the evaluation unit 144 determines whether or not there is a partial bug density equal to or higher than a predetermined value (step S44). If the evaluation unit 144 determines that there is no value equal to or greater than the predetermined value (step S44; No), the process proceeds to step S25 in FIG.

  If it is determined that there is a partial bug density equal to or higher than the predetermined value (step S44; Yes), the evaluation unit 144 selects one adjacent module (step S45). Specifically, information on adjacent modules is acquired with reference to the module position division setting information 171a.

  And the evaluation part 144 determines whether a partial bug density is more than predetermined value about an adjacent module (step S46). When it is determined that the evaluation unit 144 is smaller than the predetermined value (step S46; No), the process proceeds to step S48.

  When it is determined that the partial bug density is equal to or higher than the predetermined value (step S46; Yes), the evaluation unit 144 stores the module as a high bug density module (step S47).

  Next, the evaluation unit 144 determines whether there is an unevaluated adjacent module (step S48). If it is determined that there is an unevaluated adjacent module (step S48; Yes), the process returns to step S45. If it is determined that there is no unevaluated adjacent module (step S48; No), the process proceeds to step S25 in FIG.

  Returning to FIG. 8, the evaluation unit 144 displays the stored high bug density period and the high bug density module as the evaluation result (step S25).

  Returning to FIG. 7, the evaluation unit 144 determines whether to evaluate again under a division condition different from the division condition acquired in Step S12 (Step S17). Specifically, the evaluation unit 144 determines whether an input representing an instruction to evaluate again from the user is received via the input unit 110. And when it determines with evaluating again (step S17; Yes), a process is returned to step S12, and when it determines with not evaluating again (step S17; No), a reliability evaluation process is complete | finished.

  As described above, the software reliability evaluation apparatus 1 according to the present embodiment divides software according to development conditions that affect software quality and the division granularity, and sets a bug density for each partial source code. calculate. Thereby, it is possible to grasp in which part of the software bugs are unevenly distributed, and the user can accurately grasp the reliability of the software.

  As mentioned above, although embodiment of this invention was described, this invention is not limited by embodiment.

  For example, in the present embodiment, the module position, which is the development condition, has been described as representing the position in the hierarchical structure of the module as indicated by the module position division setting information 171a in FIG. However, the way of expressing the module position is not limited to this. For example, the module position and the division granularity may be used as the module position division setting information 171a using the calling relationship between modules.

  In the present embodiment, evaluation may be performed using the total remaining bug density and the partial remaining bug density instead of the total bug density and the partial bug density. Here, the remaining bug density D is expressed as a ratio of the number of unknown bugs of the entire software (or module) to the number of development steps of the entire software (or module) to be evaluated.

  Further, in the present embodiment, the evaluation unit 144 has been described as displaying the module determined to have a high bug density to the user, but the output mode of the result to the user is not limited to this. For example, when the correspondence relationship between the module in the module position division setting information 171a and the module described in the specification is set in advance, the module is output to indicate the module determined to have a high bug density together with the specification. May be.

  Further, the software reliability evaluation apparatus 1 according to the present invention can be realized using a normal computer system, not a dedicated system. For example, a program for executing the above operation is stored in a computer-readable recording medium (CD-ROM, MO, etc.) and distributed to a computer connected to a network, and the program is distributed to the computer system. By installing, the software reliability evaluation apparatus 1 that executes the above-described processing may be configured.

  Further, the method for providing the program to the computer is arbitrary. For example, the program may be uploaded to a bulletin board (BBS) on a communication line and distributed to a computer via the communication line. The program may be transmitted by a modulated wave obtained by modulating a carrier wave with a signal representing the program, and a device that receives the modulated wave may demodulate the modulated wave to restore the program. Then, the computer activates this program and executes it in the same manner as other applications under the control of the OS. Thus, the computer functions as the software reliability evaluation apparatus 1 that executes the above-described processing.

1 software reliability evaluation apparatus, 110 input unit, 120 output unit, 130 external I / F unit, 140 control unit, 141 division condition determination unit, 142 division unit, 143 bug density calculation unit, 144 evaluation unit, 150 ROM, 160 RAM, 170 storage unit, 171 division setting DB, 171a module position division setting information, 171b developer division setting information, 172 development condition DB, 173 bug history DB, two input device, three output device

Claims (4)

A software reliability evaluation apparatus for evaluating the quality of software composed of a plurality of modules,
A development condition storage unit that stores information indicating a module and development conditions that can affect the quality of the module at the time of development of the module in association with each other;
A division setting storage unit that stores information indicating development conditions and a division granularity that represents the size of a division unit when dividing a plurality of elements that constitute the development conditions;
A bug history storage unit representing a module and the number of bugs in the module;
A division condition determination unit that acquires information indicating a development condition that is a condition to be divided and a division granularity of the development condition;
From the development condition storage unit, the module corresponding to the development condition acquired by the division condition determination unit is specified, and the division granularity stored in the division setting storage unit and the division granularity acquired by the division condition determination unit A dividing unit for dividing the software into partial source code,
For each partial source code generated by the dividing unit, based on the number of bugs stored in the bug history storage unit, the partial bug density representing the percentage of bugs in the entire partial source code, and the percentage of bugs in the entire software An overall bug density representing, a bug density calculation unit for calculating,
Based on the partial bug density and the total bug density calculated by the bug density calculation unit, it is determined whether the partial bug density is biased with respect to the total bug density, and the partial bug density determined to be biased is determined. An evaluation unit that outputs information representing the corresponding partial source code;
A software reliability evaluation apparatus comprising: The development condition is at least one of a module position, a module developer, and a module development time in the hierarchical structure of the plurality of modules.
The software reliability evaluation apparatus according to claim 1. A software reliability evaluation method for evaluating the quality of software composed of a plurality of modules,
A development condition storage step of associating and storing in the development condition storage unit information representing a module and a development condition that can affect the quality of the module at the time of development of the module;
A division setting storage step for storing information indicating the development condition and the division granularity indicating the size of the division unit when dividing the plurality of elements constituting the development condition in the division setting storage unit;
A bug history storage step for storing information indicating the module and the number of bugs in the module in the bug history storage unit;
A division condition determining step for acquiring information indicating a development condition that is a condition to be divided and a division granularity of the development condition;
The module corresponding to the development condition acquired in the division condition determination step is identified from the development condition storage unit, and the division granularity stored in the division setting storage unit and the division granularity acquired in the division condition determination step Dividing step of dividing the software into partial source code,
For each partial source code generated in the dividing step, based on the number of bugs stored in the bug history storage unit, the partial bug density representing the percentage of bugs in the entire partial source code, and the percentage of bugs in the entire software A bug density calculating step for calculating an overall bug density representing
Based on the partial bug density and the total bug density calculated in the bug density calculating step, it is determined whether or not there is a bias in the partial bug density with respect to the total bug density. An evaluation step for outputting information representing the corresponding partial source code;
A software reliability evaluation method comprising: A program executed by a software reliability evaluation apparatus for evaluating the quality of software composed of a plurality of modules, the software reliability evaluation apparatus,
Development condition storage means for storing information indicating a module and development conditions that can affect the quality of the module at the time of development of the module in association with each other;
Division setting storage means for storing information indicating development conditions and division granularity representing the size of a division unit when dividing a plurality of elements constituting the development conditions;
A bug history storage means representing a module and the number of bugs in the module;
A split condition determining means for acquiring information indicating a development condition that is a split condition and a split granularity of the development condition;
The module corresponding to the development condition acquired by the division condition determining unit is identified from the development condition storage unit, and the division granularity stored in the division setting storage unit and the division granularity acquired by the division condition determining unit are set. A dividing means for dividing the software into partial source code,
For each partial source code generated by the dividing means, based on the number of bugs stored in the bug history storage means, a partial bug density representing the percentage of bugs in the entire partial source code, and a percentage of bugs in the entire software A bug density calculation means for calculating an overall bug density representing
Based on the partial bug density and the total bug density calculated by the bug density calculating means, it is determined whether or not there is a bias in the partial bug density with respect to the total bug density, and the partial bug density determined as having the bias is determined. Evaluation means for outputting information representing the corresponding partial source code,
A program characterized by functioning as

Images