JP5449506B1 - Product quality management device and product quality management program - Google Patents

Abstract

It is determined whether or not the quality of a design document created in each step of a software development process is appropriate.
A product quality management device 100 is a design document created in a higher-level process and defined with a plurality of requirements, and a different design tag is assigned to each defined requirement; For the description corresponding to the requirement specified in the first design document created in the lower process, enter the second design document with the tag assigned to the requirement and specify it in the first design document. The hit rate indicating how many tags are assigned to the second design document among the tags assigned to the assigned requirements is calculated and output.
[Selection] Figure 13

Description

  The present invention relates to a technique for managing the quality of a product generated in each step of a software development process.

Japanese Patent Application Laid-Open No. 2004-228561 describes the management of a product generated in each step of the software development process.
In Patent Document 1, when a product created in each process is input, a predetermined keyword is searched from the input product, and attribute information such as a searched sentence, a page number, and a file name is extracted. To do. And the traceability matrix which linked | related the attribute information extracted by the same keyword is produced. This makes it possible to manage the relationship between deliverables.

JP 2011-253345 A

  With the method described in Patent Document 1, it is possible to grasp whether or not the requirements specified in the higher-level design document are supported by any of the lower-level design documents when viewed in the entire software development process. difficult. For this reason, it is difficult to determine whether the quality of each design document is appropriate.

The product quality management device according to the present invention is:
A first design created in a first design process of a software development process including a plurality of design processes, in which a plurality of requirements are defined, and a first design in which a different first tag is assigned to each defined requirement A first design document input unit for inputting a certificate;
A second design document created in a second design process subordinate to the first design process, and a description corresponding to the requirement stipulated in the first design document is assigned to the requirement. A second design input part for inputting a second design document with a tag;
A hit rate calculation unit for calculating a hit rate indicating how many first tags among the first tags assigned to the requirements defined in the first design document are assigned to the second design document;
And an output unit for outputting the hit rate calculated by the hit rate calculation unit.

  In the deliverable quality management apparatus according to the present invention, the hit rate indicating how many tags are assigned to the lower-level design document among the tags assigned to the requirements defined in the higher-level design document is calculated. Based on this, it is possible to determine whether the quality of the lower-level design document is appropriate.

The figure which shows the example of the requirement definition document 11 concerning Embodiment 1. FIG. FIG. 3 shows an example of an external design document 12 according to the first embodiment. The figure which shows the example of the internal design document 13 which concerns on Embodiment 1. FIG. FIG. 3 is a diagram showing an example of a software design document 14 according to the first embodiment. The figure which shows the example of the unit test plan 15 which concerns on Embodiment 1. FIG. The figure which shows the example of the integration test plan document 16 concerning Embodiment 1. FIG. The figure which shows the example of the system test plan document 17 concerning Embodiment 1. FIG. The figure which shows the example of the design document comparison table 18 which compared the design documents which concern on Embodiment 1. FIG. The figure which shows the example of the plan document comparison table 19 which compared the design document which concerns on Embodiment 1, and the test plan corresponding to the design document. FIG. 3 shows an example of a traceability matrix 20 according to the first embodiment. The figure which shows the example of the total table 21 which concerns on Embodiment 1. FIG. The figure which shows the example of the V-shaped sheet | seat 22 concerning Embodiment 1. FIG. 1 is a configuration diagram of a product quality management apparatus 100 according to Embodiment 1. FIG. 5 is a flowchart showing the operation of the product quality management apparatus 100 according to the first embodiment. The figure which shows an example of the hardware constitutions of the display control apparatus 10 which concerns on the said embodiment, and the display apparatus 30. FIG.

Embodiment 1 FIG.
The software development process includes various processes such as a waterfall model and agile software development. Further, for example, there are various models of the waterfall model depending on how much the process is subdivided.
Here, description will be made using a waterfall model including a requirement definition process, an external design process, an internal design process, a software design process, a development unit test process, an integration test process, and a system test process. However, the product quality management technology described below is not limited to this waterfall model, but can be applied to other waterfall models and other development processes.

Here, a requirement definition document 11 is created in the requirement definition process, an external design document 12 is created in the external design process, an internal design document 13 is created in the internal design process, and a software design document 14 is created in the development process. Assume that a unit test plan 15 is created in the unit test process, an integration test plan 16 is created in the integration test process, and a system test plan 17 is created in the system test process.
The unit test process is a process for performing a test corresponding to the software design document 14, the combined test process is a process for performing a test corresponding to the internal design document 13, and the system test process is a test corresponding to the external design document 12. It is assumed that this is a process to be performed.

FIG. 1 is a diagram illustrating an example of the requirement definition document 11 according to the first embodiment.
The requirement definition document 11 defines various requirements for software to be developed. This requirement includes functional requirements realized by software and performance requirements to be satisfied by software.
In the requirement definition document 11, the text 1 is described for each of ID1 and ID2 (for example, ID1 is a chapter and ID2 is a section). If the requirement is defined in the text 1, the first tag is assigned to the requirement.

FIG. 2 is a diagram illustrating an example of the external design document 12 according to the first embodiment.
The external design document 12 defines the functions and data flow provided by the development target software. In the external design document 12, functions and data flows are defined so as to satisfy the requirements defined in the requirement definition document. In principle, the external design document 12 is described so as to support all the requirements stipulated in the requirement definition document, but some of the requirements may not be supported. If there are requirements not supported by the external design document 12, the unsupported requirements are supported by the internal design document 13 or the software design document 14.
In the external design document 12, the text 2 is described for each of ID1, ID2, and ID3 (for example, ID3 is a term). If the requirement defined in the requirement definition document 11 is supported by the text 2, the first tag assigned to the requirement is attached. Further, when the requirement is defined in the text 2, the second tag is assigned to the requirement.

FIG. 3 is a diagram illustrating an example of the internal design document 13 according to the first embodiment.
The internal design document 13 defines a method for realizing the functions and data flow defined in the external design process by software. The internal design document 13 is defined by a software implementation method so as to satisfy the requirements defined in the external design document 12 (and the requirement definition document 11). As a general rule, the internal design document 13 is described so as to support all the requirements defined in the external definition document, but some of the requirements may not be supported. If there are requirements not supported by the internal design document 13, the unsupported requirements are supported by the software design document 14.
In the internal design document 13, the text 3 is described for each of ID1, ID2, ID3, and ID4 (for example, ID4 is an article). If a requirement that is not supported by the external design document 12 among the requirements specified in the requirement definition document 11 is supported by the main text 3, the first tag assigned to the requirement is attached. Is done. Similarly, when the requirement defined in the external design document 12 is supported by the main body 3, the second tag assigned to the requirement is attached. Further, when the requirement is defined in the text 3, the third tag is assigned to the requirement.

FIG. 4 is a diagram illustrating an example of the software design document 14 according to the first embodiment.
The software design document 14 defines the actual program processing in accordance with the implementation method defined in the internal design process. In the software design document 14, program processing is defined so as to satisfy the requirements defined in the internal design document 13 (and the external design document 12 and the requirement definition document 11). In principle, the software design document 14 is written to support all requirements defined in the internal definition.
The software design document 14 describes the text 4 for each of ID1, ID2, ID3, ID4, and ID5 (for example, ID5 is a branch number). Of the requirements specified in the requirement definition document 11, if a requirement that is not supported by the external design document 12 and the internal design document 13 is supported by the main text 4, it is assigned to that requirement. A first tag is attached. Similarly, if a requirement that is not supported by the internal design document 13 among the requirements specified by the external design document 12 is supported by the body 4, the second tag assigned to the requirement is Attached. Similarly, when a requirement defined in the internal design document 13 is supported by the text 4, a third tag assigned to the requirement is attached. Further, when the requirement is defined in the text 4, the fourth tag is assigned to the requirement.

FIG. 5 is a diagram showing an example of the unit test plan 15 according to the first embodiment.
The unit test plan 15 defines a function test plan for each program unit. In the unit test plan 15, a test plan is defined so as to satisfy all the requirements defined in the software design document 14.
The unit test plan 15 describes the test contents 1 for each of ID1, ID2, ID3, ID4, and ID5 in accordance with the software design document 14. When the requirement specified in the software design document 14 is supported by the test contents 1, the fourth tag assigned to the requirement is attached.

FIG. 6 is a diagram illustrating an example of the integration test plan 16 according to the first embodiment.
The integration test plan 16 defines a test plan for an interface function between programs obtained by combining a plurality of programs. In the integration test plan 16, the test plan is defined so as to satisfy all the requirements defined in the internal design document 13.
The integration test plan 16 describes the test content 2 for each of ID1, ID2, ID3, and ID4 in accordance with the internal design document 13. If the requirement specified in the internal design document 13 is supported by the test content 2, the third tag assigned to the requirement is attached.

FIG. 7 is a diagram illustrating an example of the system test plan document 17 according to the first embodiment.
The system test plan 17 defines a function test plan for the entire system by combining all programs. In the system test plan 17, a test plan is defined so as to satisfy all the requirements defined in the external design document 12.
In the system test plan 17, test contents 3 are described for each of ID 1, ID 2, and ID 3 in accordance with the external design document 12. If the requirement defined in the external design document 12 is supported by the test content 3, the second tag assigned to the requirement is attached.

FIG. 8 is a diagram illustrating an example of the design document comparison table 18 that compares the design documents according to the first embodiment. FIG. 8 shows a design document comparison table 18 in which the requirement definition document 11 and the external design document 12 are compared.
In the design document comparison table 18 comparing the design documents, all the tags assigned in the higher-level design document are extracted, and the description content of each design document is shown for each extracted tag. In FIG. 8, all the first tags assigned to the higher-level requirement definition document 11 are extracted. And for every 1st tag, the 1st tag was attached | subjected among ID1, ID2, the text 1 to which the 1st tag was attached | subjected among the description of the requirement definition document 11, and the external design document 12. ID1, ID2, ID3, and text 2 are shown.

FIG. 9 is a diagram illustrating an example of the plan comparison table 19 in which the design document according to the first embodiment is compared with the test plan corresponding to the design document. FIG. 9 shows a plan comparison table 19 in which the external design document 12 and the system test plan 17 are compared.
In the plan comparison table 19 comparing the design document and the test plan corresponding to the design document, all the tags assigned to the design document are extracted, and the description content of the design document for each extracted tag, The contents of the test plan are indicated. In FIG. 9, all the second tags assigned to the external design document 12 are extracted. And for every 2nd tag, among the description of ID1, ID2, ID3 to which the 2nd tag was attached | subjected and the external design document 12, the text 2 to which the 2nd tag was attached, and the system test plan document 17 Among the descriptions, the test content 3 to which the second tag is attached is shown.

FIG. 10 is a diagram illustrating an example of the traceability matrix 20 according to the first embodiment. FIG. 10 shows a traceability matrix 20 in which descriptions between the requirement definition document 11 and the external design document 12 are generated based on the design document comparison table 18 shown in FIG.
The traceability matrix 20 is created by extracting only necessary items from the design document comparison table 18. Here, the traceability matrix 20 is created by extracting items other than the ID from the design document comparison table 18 shown in FIG.
The method for generating the traceability matrix 20 from the plan document comparison table 19 is the same as the method for generating the traceability matrix 20 from the design document comparison table 18.

FIG. 11 is a diagram illustrating an example of the aggregation table 21 according to the first embodiment. FIG. 11 shows a tabulation table 21 that is generated based on the design document comparison table 18 shown in FIG. 8 and totals whether or not each requirement specified in the requirement definition document 11 is supported by the external design document 12. .
The tabulation table 21 indicates the number of hits, which is the number supported by the lower-level design document, for each tag included in the design document comparison table 18. In FIG. 11, for each first tag shown in FIG. 8, the number of hits, which is the number supported by the lower external design document 12, and the remainder indicating the number not supported by the lower design document are shown. Yes.
The number of hits is the number of hits with duplicates counted independently and hits with no duplicates counted as 1 as a whole when one tag is supported at multiple places in the lower design document. There are numbers. For example, in the case of the first tag “Y-00011”, ID1, ID2, and ID3 of the external design document 12 are supported at two locations, “111” and “113”, respectively. Therefore, the number of hits with duplication is 2, and the number of hits without duplication is 1.
In FIG. 11, the total number of hits and the remaining number is 5 with duplicates, 3 with no duplicates, and 2 with the remaining. That is, three of the five requirements described in the requirement definition document 11 are supported at five locations in the external design document 12, and two of the five requirements described in the requirement definition document 11 are supported. This requirement is not supported by the external design document 12.
The method for generating the tabulation table 21 from the plan document comparison table 19 is the same as the method for generating the tabulation table 21 from the design document comparison table 18.

FIG. 12 is a diagram illustrating an example of the V-shaped sheet 22 according to the first embodiment.
In the V-shaped sheet 22, information about each design document and each test plan is displayed in a V shape in accordance with the V-shaped development process. That is, each design document and each of the design documents and each of the design documents are arranged so that the hierarchy gradually decreases from the requirement definition document 11 to the software design document 14 and gradually increases from the unit test plan 15 to the system test plan document 17. Information about the test plan is presented.
In the V-shaped sheet 22, the number of requirements defined in each design document (reference numeral 31) and the number of requirements defined in the higher-level design document in each design document (number of hits with duplicates and hits without duplicates) (Number) (reference numeral 32) and a hit rate (reference numeral 33) indicating the proportion of the requirements defined in the higher-level design document up to that design document. In addition, in the V-shaped sheet 22, for the requirements specified in the corresponding design document, the number (reference numeral 34) supported in the test plan and the requirements specified in the corresponding design document were supported in the test plan. A hit rate (reference numeral 35) indicating the ratio is shown.
In FIG. 12, the information related to the requirements defined in the requirement definition document 11 is appended with “a”, and the information related to the requirements defined in the external design document 12 is appended with “b” after the code. Information relating to the requirements defined in the document 13 is denoted by “c”, and information relating to the requirements defined in the software design document 14 is denoted by “d”.

Descriptions about requirements defined in the requirement definition document 11 in FIG. 12 will be described.
In the requirement definition document 11, five requirements are defined (see column 31a).
In the external design document 12, the number of hits with duplication is 5 and the number of hits without duplication is 3 for the five requirements defined in the requirement definition document 11 (see the column 32a of the external design document 12). ). That is, in the external design document 12, three requirements among the five requirements described in the requirement definition document 11 are supported at five locations. Therefore, the hit rate in the external design document 12 is 60% (3/5), and there are two unsupported requirements (residuals) (see the column 33a on the left side of the external design document 12). .
In the internal design document 13, the number of hits with duplication is 1 and the number of hits without duplication is 1 for the remaining two requirements (remaining cases) (see the column 32a in the internal design document 13). In other words, in the internal design document 13, one of the remaining two requirements is supported at one location. Therefore, the hit rate from the external design document 12 to the internal design document 13 is 80% (4/5), and there is one unsupported requirement (remaining) (the sign on the left side of the internal design document 13). 33a).
In the software design document 14, the number of hits with duplication is 1 and the number of hits without duplication is 1 for the remaining one requirement (remainder) (see the column 32 a in the software design document 14). In other words, the software design document 14 supports the remaining one requirement at one location. Therefore, the hit rate from the external design document 12 to the software design document 14 is 100% (5/5), and there is no unsupported requirement (remainder) (the column 33a on the left side of the software design document 14). reference).

Descriptions about requirements defined in the external design document 12 in FIG. 12 will be described.
In the external design document 12, 16 requirements are defined (see column 31b).
In the internal design document 13, the number of hits with duplication is 20 and the number of hits without duplication is 8 for the 16 requirements defined in the external design document 12 (see the column 32 b of the internal design document 13). ). That is, in the external design document 12, eight requirements among the 16 requirements described in the requirement definition document 11 are supported at 20 locations. Therefore, the hit rate in the internal design document 13 is 50% (8/16), and there are 8 unsupported requirements (remainder) (see the column 33b on the left side of the internal design document 13). .
In the software design document 14, for the remaining 8 requirements (remaining cases), the number of hits with duplication is 9, and the number of hits without duplication is 4 (see the column 32b in the software design document 14). That is, the software design document 14 supports nine requirements for four of the remaining eight requirements. Therefore, the hit rate from the internal design document 13 to the software design document 14 is 75% (12/16), and there are four unsupported requirements (residues) (the code on the left side of the software design document 14). 33b).
Further, in the system test plan document 17 corresponding to the external design document 12, four requirements among the 16 requirements defined in the external design document 12 are supported (see the column 34b). Therefore, the hit rate in the system test plan 17 is 25% (4/16) (see the column 35b).
Here, the reason why the fields 33b, 33c, 35b, and 35c are hatched is to warn that the hit rate is lower than a predetermined threshold.

  The contents of the remaining internal design document 13, software design document 14, unit test plan document 15, and integration test plan document 16 can also be confirmed according to the above description.

FIG. 13 is a configuration diagram of the product quality management apparatus 100 according to the first embodiment.
The product quality management apparatus 100 includes a product input unit 101 (an example of a first design document input unit, a second design document input unit, a third design document input unit, and a first test plan document input unit), and a product storage unit. 102, a comparison unit 103, a matrix generation unit 104, a matrix storage unit 105, a hit rate calculation unit 106, an output unit 107, a reference setting unit 108, a hit rate determination unit 109, and a warning unit 110.

The product input unit 101 inputs a product created in each step in the software development process using an input device. Here, the product input unit 101 includes the requirement definition document 11, the external design document 12, the internal design document 13, the software design document 14, the unit test plan document 15, the integration test plan document 16, and the system test illustrated in FIGS. 1 to 7. The plan 17 is input.
The product storage unit 102 stores the product input by the product input unit 101 in a storage device.

The comparison unit 103 compares the design documents input by the product input unit 101 with the processing device to generate the design document comparison table 18 described based on FIG. 8, and also tests the design document and the design document. A plan comparison table 19 described based on FIG. 9 is generated by comparing with the plan.
That is, the comparison unit 103 compares the requirement definition document 11 and the external design document 12 with a design document comparison table 18a, compares the requirement definition document 11 with the internal design document 13, and compares the requirement definition document 11 with the requirement definition document 11. A design document comparison table 18c comparing the software design document 14, a design document comparison table 18d comparing the external design document 12 and the internal design document 13, and a design document comparison table comparing the external design document 12 and the software design document 14. 18e, a design document comparison table 18f comparing the internal design document 13 and the software design document 14 is generated. The comparison unit 103 also includes a plan comparison table 19a that compares the external design document 12 and the system test plan 17, a plan comparison table 19b that compares the internal design document 13 and the combined test plan 16, and a software design document. A plan comparison table 19c comparing 14 and the unit test plan 15 is generated.

Based on FIG. 10, the matrix generation unit 104 associates descriptions between deliverables for each requirement based on the design document comparison table 18a-f and the plan comparison table 19a-c generated by the comparison unit 103 by the processing device. The described traceability matrix 20 is generated.
That is, the matrix generation unit 104 includes a traceability matrix 20a based on the design document comparison table 18a, a traceability matrix 20b based on the design document comparison table 18b, a traceability matrix 20c based on the design document comparison table 18c, and a traceability matrix based on the design document comparison table 18d. 20d, traceability matrix 20e based on design document comparison table 18e, traceability matrix 20f based on design document comparison table 18f, traceability matrix 20g based on plan document comparison table 19a, traceability matrix 20h based on plan document comparison table 19b, plan document comparison table A traceability matrix 20i based on 19c is generated.
The matrix storage unit 105 stores the traceability matrix 20 generated by the matrix generation unit 104 in a storage device.

The hit rate calculation unit 106 converts each requirement defined in the higher-level design document into the lower-level design based on the design document comparison table 18a-f and the plan document comparison table 19a-c generated by the comparison unit 103 by the processing device. Whether or not it is supported by the certificate or the corresponding test plan, and generates the aggregation table 21 described based on FIG.
In other words, the hit rate calculation unit 106 includes a tabulation table 21a based on the design document comparison table 18a, a tabulation table 21b based on the design document comparison table 18b, a tabulation table 21c based on the design document comparison table 18c, and a tabulation based on the design document comparison table 18d. Table 21d, summary table 21e based on design comparison table 18e, summary table 21f based on design comparison table 18f, summary table 21g based on plan comparison table 19a, summary table 21h based on plan comparison table 19b, plan comparison A summary table 21i based on the table 19c is generated.
Then, the hit rate calculation unit 106 indicates, from each of the generated aggregation tables 21a-i, the ratio of the requirements defined in the higher-level design document supported by the lower-level design document or the corresponding test plan. Calculate the hit rate.
The output unit 107 outputs the hit rate calculated by the hit rate calculation unit 106 on the V-shaped sheet 22 described with reference to FIG.

The reference setting unit 108 sets a threshold value for the hit rate for each design document and test plan document using the input device. That is, the reference setting unit 108 sets the hit rate threshold value for each of the column 33 and the column 35 (shown by an ellipse in FIG. 12) shown in FIG.
The hit rate determination unit 109 determines whether the hit rate calculated by the hit rate calculation unit 106 is lower than the threshold set by the reference setting unit 108 by the processing device.
When the hit rate determination unit 109 determines that the hit rate is lower than the threshold, the warning unit 110 outputs a warning (hatching in FIG. 12) on the V-shaped sheet 22.

FIG. 14 is a flowchart showing the operation of the product quality management apparatus 100 according to the first embodiment.
(S1: Deliverable input process)
The product input unit 101 inputs a product.
The product storage unit 102 stores the input product.

(S2: Comparison process)
The comparison unit 103 generates the design document comparison table 18 and the plan document comparison table 19 by comparing the products input in S1 with other products input in the past.
For example, when the external design document 12 is input in S1, the product of the upper process should have already been input, so the comparison unit 103 has previously input the external design document 12 input in S1. The design document comparison table 18 is generated in comparison with the requirement definition document 11 which is a product of the higher-order process. In addition, when additional writing or the like is performed on the external design document 12, there may be a case where a product of a lower process such as the internal design document 13 or the system test plan document 17 has already been input. In this case, the comparison unit 103 compares the external design document 12 input in S1 with the product of the lower-order process input in the past, and regenerates the design document comparison tables (18d, 18e).
The comparison unit 103 determines the upper / lower order of the design document and the plan document based on the number of IDs (ID1, ID2,... IDn). That is, as the number of design documents and design document IDs increases by one, the first design document, the second design document, and the third design document are located from the upper level to the lower level.

(S3: Matrix generation processing)
The matrix generation unit 104 generates the traceability matrix 20 based on the design document comparison table 18 and the plan document comparison table 19 generated in S2.
For example, when the design document comparison table 18 that compares the requirement definition document 11 and the external design document 12 is generated in S2, the matrix generation unit 104 describes the description between the requirement definition document 11 and the external design document 12. Is generated. When a plurality of design document comparison tables 18 and plan document comparison tables 19 are generated in S2, the matrix generation unit 104 generates a traceability matrix 20 corresponding to each design document comparison table 18 and each plan document comparison table 19. To do.
The matrix storage unit 105 stores the generated traceability matrix 20.

(S4: Hit rate calculation process)
The hit rate calculation unit 106 generates a tabulation table 21 based on the design document comparison table 18 and the plan document comparison table 19 generated in S2, and calculates the hit rate.
For example, when the design document comparison table 18 that compares the requirement definition document 11 and the external design document 12 is generated in S2, the hit rate calculation unit 106 converts each requirement specified in the requirement definition document 11 to the external A tabulation table 21 is generated in which whether or not the design document 12 supports is tabulated. Then, the hit rate calculation unit 106 calculates a hit rate indicating the ratio of the requirements specified in the requirement definition document 11 supported by the external design document 12. When a plurality of design document comparison tables 18 and plan document comparison tables 19 are generated in S2, the hit rate calculation unit 106 creates a tabulation table 21 corresponding to each design document comparison table 18 and each plan document comparison table 19. Generate and calculate the hit rate.
The hit rate calculation unit 106 adds the number of hits in the higher-level design document when calculating the hit rate in the third and subsequent design documents. For example, when calculating the hit rate in the internal design document 13 for the requirement definition document 11, the hit number for the requirement definition document 11 in the external design document 12, which is a higher-level design document of the internal design document 13, is added to Calculate the rate.

(S5: Hit rate determination process)
The hit rate determination unit 109 determines whether or not the hit rate calculated in S4 is lower than the threshold set in advance by the reference setting unit 108.
For example, when the hit rate indicating the ratio of the requirement specified in the requirement definition document 11 supported by the external design document 12 is calculated in S4, the requirement specified in the requirement definition document 11 is supported by the external design document 12. It is determined whether or not the hit rate calculated in S4 is lower than the threshold value for the ratio being played.

(S6: Output processing)
The output unit 107 outputs the number of hits described in the tabulation table 21 generated in S4, the hit rate calculated in S4, and the like on the V-shaped sheet 22.
For example, when the hit rate indicating the ratio of the requirement specified in the requirement definition document 11 in S4 is supported by the external design document 12, the hit rate calculated in the corresponding column of the V-shaped sheet 22, In the external design document 12, the number of hits with duplicates and the number of hits without duplicates, which indicate how many of the requirements specified in the requirement definition document 11 are supported, are indicated by the V-shaped sheet 22. Shown in If the hit rate or the like has already been shown in the other column of the V-shaped sheet 22 and there is no change in the column, the description in the column is left without being deleted.
Further, when it is determined in S5 that the hit rate is lower than the threshold value, the warning unit 110 outputs a warning in a corresponding column of the V-shaped sheet 22.

  As described above, the product quality management apparatus 100 updates and outputs the V-shaped sheet 22 every time a product is newly input. In particular, the V-shaped sheet 22 is updated and output not only when a new product is created but also when the product is modified such as additional writing.

  In the product quality management apparatus 100 according to the first embodiment, by calculating how many tags are assigned to the lower-level design document among the tags assigned to the requirements defined in the higher-level design document, A hit ratio indicating the ratio of the requirements specified in the higher-level design document being supported by the lower-level design document was calculated. Based on the calculated hit rate, it is possible to determine whether the quality of the lower-level design document is appropriate. As a result, the quality of the lower-level design document can be improved.

In particular, in the product quality management apparatus 100 according to Embodiment 1, among the tags assigned to the requirements stipulated in the higher-level design document (for example, the requirement definition document 11), how many tags are immediately lower-level design documents. It is not only calculated whether it is given to (external design document 12). If a tag assigned to a requirement specified in a higher-level design document includes a tag that is not assigned to a lower-level design document, some of the tags are further subordinate to the design document (internal It is calculated whether it is given to the design document 13).
For example, there may be a case where all the requirements defined in the requirement definition document 11 are not supported by the external design document 12 and some are supported by the internal design document 13. In such a case, it is possible to appropriately determine whether the quality of the external design document 12 and the internal design document 13 is appropriate.

  In the product quality management apparatus 100 according to the first embodiment, how many tags are assigned to the test plan corresponding to the design document among the tags assigned to the requirements defined in the design document. The hit rate indicating the proportion of the requirements specified in the design document that are supported by the corresponding test plan was calculated. Based on the calculated hit rate, it is possible to determine whether the quality of the test plan is appropriate. As a result, the quality of the test plan can be improved.

  As described above, the waterfall model includes various models depending on how much the process is subdivided. The product quality management technique described above is not limited to the waterfall model described above, but can be applied to other waterfall models as well.

  As described above, the software development process includes not only the waterfall model but also various processes such as agile software development. The product quality management technology described above is applicable not only to the waterfall model but also to other development processes.

  In the above description, the design document and the test plan document are tabulated. However, this is to make the above description easy to understand, and the design document actually used does not need to be in a table format.

In the above description, when a requirement is defined in the text of the design document, a tag is assigned to that part. Although tag assignment may be performed manually, it is time consuming, and thus a tag may be automatically generated from an ID.
For example, in the requirement definition document 11, the value of ID1 and ID2 may be added after “Y-000” to generate the first tag. That is, if ID1 is 1 and ID2 is 2, the first tag is Y-00012. Similarly, in the external design document 12, the values of ID1, ID2, and ID3 may be added after “G-00” to generate the second tag. That is, if ID1 is 1, ID2 is 2, and ID3 is 3, the first tag is Y-00123. Similarly, the third tag in the internal design document 13 and the fourth tag in the software design document 14 can be automatically generated from the ID.
However, a tag assigned to a higher-level design document cannot be automatically attached to a lower-level design document, and must be performed manually. For example, the first tag in the external design document 12 is attached when the requirement specified in the requirement definition document 11 is supported in the text 2. For this reason, it is necessary to check whether the requirement defined in the requirement definition document 11 is supported in the main text 2, and the first tag in the external design document 12 cannot be automatically generated. Similarly, the first tag and the second tag in the internal design document 13 and the first tag, the second tag, and the third tag in the software design document 14 cannot be automatically generated.

FIG. 15 is a diagram illustrating an example of a hardware configuration of the product quality management apparatus 100 according to the above embodiment.
As illustrated in FIG. 15, the product quality management apparatus 100 includes a CPU 911 (also referred to as a central processing unit, a central processing unit, a processing unit, an arithmetic unit, a microprocessor, a microcomputer, and a processor) that executes a program. Yes. The CPU 911 is connected to the ROM 913, the RAM 914, the LCD 901 (Liquid Crystal Display), the keyboard 902 (K / B), the communication board 915, and the magnetic disk device 920 via the bus 912, and controls these hardware devices. Instead of the magnetic disk device 920 (fixed disk device), a storage device such as an optical disk device or a memory card read / write device may be used. The magnetic disk device 920 is connected via a predetermined fixed disk interface.

  An operating system 921 (OS), a window system 922, a program group 923, and a file group 924 are stored in the magnetic disk device 920 or the ROM 913. The programs in the program group 923 are executed by the CPU 911, the operating system 921, and the window system 922.

The program group 923 includes “product input unit 101”, “comparison unit 103”, “matrix generation unit 104”, “hit rate calculation unit 106”, “output unit 107”, “reference setting unit 108” in the above description. ”,“ Hit rate determination unit 109 ”,“ warning unit 110 ”, and the like, software, programs and other programs that execute the functions described above are stored. The program is read and executed by the CPU 911.
In the file group 924, information, data, signal values, variable values, and parameters stored in the “product storage unit 102” and “matrix storage unit 105” in the above description are stored as items of the “database”. The The “database” is stored in a recording medium such as a disk or a memory. Information, data, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPU 911 via a read / write circuit, and extracted, searched, referenced, compared, and calculated. Used for the operation of the CPU 911 such as calculation / processing / output / printing / display. Information, data, signal values, variable values, and parameters are temporarily stored in the main memory, cache memory, and buffer memory during the operation of the CPU 911 for extraction, search, reference, comparison, calculation, calculation, processing, output, printing, and display. Is remembered.

In the above description, the arrows in the flowchart mainly indicate input / output of data and signals, and the data and signal values are recorded in a memory of the RAM 914, other recording media such as an optical disk, and an IC chip. Data and signals are transmitted online by a bus 912, signal lines, cables, other transmission media, and radio waves.
In addition, what is described as “to part” in the above description may be “to circuit”, “to device”, “to device”, “to means”, and “to function”. It may be “step”, “˜procedure”, “˜processing”. In addition, what is described as “˜device” may be “˜circuit”, “˜device”, “˜means”, “˜function”, and “˜step”, “˜procedure”, “ ~ Process ". That is, what is described as “˜unit” may be realized by firmware stored in the ROM 913. Alternatively, only software, hardware such as elements, devices, substrates, and wirings, a combination of software and hardware, or a combination of firmware may be used. Firmware and software are stored in a recording medium such as ROM 913 as a program. The program is read by the CPU 911 and executed by the CPU 911. That is, the program causes a computer or the like to function as the “˜unit” described above. Alternatively, the computer or the like is caused to execute the procedures and methods of “to part” described above.

  11 Requirement Definition Document, 12 External Design Document, 13 Internal Design Document, 14 Software Design Document, 15 Unit Test Plan, 16 Integration Test Plan, 17 System Test Plan, 18 Design Document Comparison Table, 19 Plan Comparison Table, 20 Traceability matrix, 21 tabulation table, 22 V-shaped sheet, 100 product quality management device, 101 product input unit, 102 product storage unit, 103 comparison unit, 104 matrix generation unit, 105 matrix storage unit, 106 hit rate calculation unit 107 output unit 108 reference setting unit 109 hit rate determination unit 110 warning unit

Claims (6)

A first design created in a first design process of a software development process including a plurality of design processes, in which a plurality of requirements are defined, and a first design in which a different first tag is assigned to each defined requirement A first design document input unit for inputting a document by an input device ;
A second design document created in a second design process subordinate to the first design process, and a description corresponding to the requirement stipulated in the first design document is assigned to the requirement. A second design document input unit for inputting the second design document with the tag by the input device ;
A product storage unit that stores in a storage device the first design document input by the first design document input unit and the second design document input by the second design document input unit;
The first design document and the second design document are read from the storage device, and the number of first tags among the first tags assigned to the requirements defined in the first design document is the second design document. A hit rate calculation unit that calculates a hit rate indicating whether or not it is assigned to the processor ,
A product quality management device comprising: an output unit that outputs a hit rate calculated by the hit rate calculation unit. The product quality management device further includes:
A third design document created in a third design process subordinate to the second design process, wherein a description corresponding to the requirement stipulated in the first design document is assigned to the requirement. A third design document input unit for inputting a third design document with a tag by an input device ;
The hit rate calculation unit calculates a hit rate indicating how many first tags of the first tags are assigned to at least one of the second design document and the third design document. The deliverable quality management apparatus according to claim 1, wherein In the second design document, a plurality of requirements are defined, and a different second tag is assigned to each defined requirement.
In the third design document, a second tag assigned to the requirement is attached to the description corresponding to the requirement stipulated in the second design document,
The hit rate calculation unit calculates a hit rate indicating how many second tags among the second tags assigned to the requirements specified in the second design document are assigned to the third design document. The product quality management apparatus according to claim 2, wherein The software development process includes a test process corresponding to each design process,
The product quality management device further includes:
A first test plan that defines test contents to be performed in a first test process corresponding to the first design process, and for the test items corresponding to the requirements defined in the first design document, A first test plan input unit for inputting the first test plan with the assigned first tag by an input device ;
The hit rate calculation unit calculates a hit rate indicating how many first tags assigned to the requirements defined in the first design document are assigned to the first test plan. The product quality control device according to claim 1, wherein the product quality control device is a product quality control device. The product quality management device further includes:
A hit rate determination unit for determining by the processing device whether or not the hit rate is lower than a predetermined threshold;
The deliverable quality management apparatus according to any one of claims 1 to 4, further comprising a warning unit that warns when the hit rate determination unit determines that the hit rate is lower than a predetermined threshold. A first design created in a first design process of a software development process including a plurality of design processes, in which a plurality of requirements are defined, and a first design in which a different first tag is assigned to each defined requirement A first design document input process for inputting a document;
A second design document created in a second design process subordinate to the first design process, and a description corresponding to the requirement stipulated in the first design document is assigned to the requirement. A second design document input process for inputting a second design document with a tag;
A deliverable storage process for storing in the storage device the first design document input in the first design document input process and the second design document input in the second design document input process;
The first design document and the second design document are read from the storage device, and the number of first tags among the first tags assigned to the requirements defined in the first design document is the second design document. Hit rate calculation processing for calculating the hit rate indicating whether or not
A product quality management program for causing a computer to execute an output process for outputting a hit ratio calculated in the hit ratio calculation process.

Images