WO2015088067A1

WO2015088067A1 - Software quality element extraction module and method, and computer-readable recording medium having, recorded thereon, program for implementing software quality element extraction method

Info

Publication number: WO2015088067A1
Application number: PCT/KR2013/011427
Authority: WO
Inventors: 박철민; 이규열; 한익준; 윤광식; 배현섭
Original assignee: 슈어소프트테크주식회사
Priority date: 2013-12-10
Filing date: 2013-12-10
Publication date: 2015-06-18
Also published as: KR101547248B1; KR20150067827A

Abstract

One embodiment relates to a software quality element extraction module and method and a computer-readable recording medium having, recorded thereon, a program for implementing the software quality element extraction method. The software quality element extraction module according to the embodiment, which is a quality element extraction module that extracts quality elements used in a software quality evaluation module, comprises: a verifier for extracting verification data by verifying a source code; and a quality element extractor for extracting the quality elements from the extracted verification data.

Description

A computer readable recording medium having recorded thereon a software quality component extraction module and method and a program for executing the software quality component extraction method.

Embodiments relate to a software quality component extraction module and method and a computer readable recording medium having recorded thereon a program for executing the software quality component extraction method.

In the software development process, the method for evaluating the quality of the software is mostly based on the manual method of analyzing the quality data of the software by system developers.

As an example of a passive method, the quality data is visually simply listed on a display device such as a monitor.

Since this manual method simply lists a lot of quality data, it is difficult for a developer to intuitively determine the quality of the software.

An embodiment provides a computer-readable recording medium having recorded thereon a quality element extraction module and method of software for extracting quality elements used in a quality evaluation module of software and a program for executing the software quality element extraction method.

A module according to an embodiment includes a quality factor extraction module for extracting a quality factor used in a quality evaluation module of software, comprising: a verification performer for verifying source code to extract verification data; And a quality factor extractor for extracting the quality factor from the extracted verification data.

In addition, the module according to the embodiment is a quality factor extraction module for extracting a quality factor used in the quality evaluation module of the software, and includes a verification performer for verifying source code, wherein the verification performer extracts verification data from the source code. And extracting at least one verification tool unit, wherein the verification tool unit transmits some verification data previously promised in the verification data to the quality evaluation module through an application programming interface (API).

In addition, the method according to the embodiment, the quality factor extraction method for extracting the quality factor used in the quality evaluation module of the software, source code verification step of extracting the verification data by verifying the source code; And a quality factor generation step of extracting the quality factor from the extracted verification data.

In addition, the method according to the embodiment, the quality element extraction method for extracting the quality element used in the quality evaluation module of the software, the source code verification step of verifying the source code to extract the verification data; And transmitting some verification data previously promised in the verification data to the quality evaluation module through an application programming interface (API).

Using a computer-readable recording medium having recorded thereon a program for executing the software quality factor extraction module and method and software quality factor extraction method according to the embodiment, it is possible to extract quality factors that can be used in the software quality evaluation module. There is an advantage to that.

1 is a block diagram of a software quality management system according to an embodiment.

FIG. 2 is a block diagram for describing in detail the quality factor extraction module 300 shown in FIG. 1.

3 is an example of a calculation file.

4 is a detailed block diagram of the quality assessment module 500 shown in FIG. 1.

5 to 8 are examples in which a quality score is displayed on a display device.

9 is a flowchart of a software quality management method according to the embodiment.

FIG. 10 is a flowchart detailing the quality factor extraction step S300 shown in FIG. 9.

FIG. 11 is a flow chart embodying the quality evaluation step S500 shown in FIG. 9.

The above objects, features and advantages will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, whereby those skilled in the art may easily implement the technical idea of the present invention. There will be. In addition, in describing the present invention, when it is determined that the detailed description of the known technology related to the present invention may unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

Referring to FIG. 1, the quality management system according to the embodiment may include a source code file repository 100, a quality element extraction module 300, a quality evaluation module 500, and a display module 700.

The source code file repository 100 is a device for storing source code files of specific software. Here, the source code file is a file including the source code constituting the software, the source code file may exist as one, or may exist in plurality. Multiple code files can make up a project.

The quality factor extraction module 300 receives a source code file. The received source code file may be a plurality of source code files. The single or plural source code files are stored in the external source code file repository 100 and may be input to the quality factor extraction module 100 at the request of the quality factor extraction module 100 or at the request of an external user.

The quality factor extraction module 300 extracts a plurality of quality elements from the received source code file, and outputs the extracted quality elements. The output quality elements are input to the quality evaluation module 500.

The quality factor extracted by the quality factor extraction module 300 from a source code file refers to various criteria for determining the quality of a specific software. How the quality factor extraction module 300 extracts the quality factor will be described in detail with reference to FIGS. 2 to 3.

The quality evaluation module 500 receives the quality factor, and extracts and outputs a quality score using the received quality factor. How the quality evaluation module 500 extracts the quality score using the quality factor will be described in detail with reference to FIG. 4.

The quality factor extraction module 300 and the quality evaluation module 500 may be implemented in one piece of software, or the quality factor extraction module 300 and the quality evaluation module 500 may be implemented as separate software.

The display module 700 shows the quality score output from the quality evaluation module 500 to the user. The display module 700 may be implemented as hardware such as a monitor.

FIG. 2 is a block diagram for describing in detail the quality factor extraction module 300 illustrated in FIG. 1.

Referring to FIG. 2, the quality factor extraction module 300 may include a verification performer 310 and a quality factor extractor 330.

The verification performer 310 receives the source code file from the source code repository 100 and verifies the received source code file. The verification performer 310 may include at least one verification tool part (first verification tool part 311, second verification tool part 313, and third verification tool part 315) to verify the source code in the source code file. ) May be included. The

verification tools

311, 313, 315 may include a code inspector, a controller tester, a compiler, and other verification tools.

For example, when the first verification tool 311 is a code inspector, the first verification tool 311 may calculate predetermined verification data from the source code and output the calculated verification data as one calculation file. Can be. In the calculation file, as shown in FIG. 3, the number of items that violated coding rules in a specific project (MISRA Test Suite) (the total number of violations) and the diagnosis message, rule, severity, source, Data about functions, lines, and paths can be included. Here, the second verification tool 313 and the third verification tool 315 may also output a calculation file similarly to the first verification tool 311.

The second verification tool unit 313 of the verification performer 310 may store the verification data calculated from the source code in the database DB without outputting the verification data as a separate calculation file. Here, the first verification tool 311 and the third verification tool 315 may store verification data in the database similarly to the second verification tool 313.

Meanwhile, the third verification tool unit 315 of the verification performer 310 may directly transmit verification data calculated from the source code to the quality evaluation module 500. In detail, the verification data calculated by the third verification tool unit 315 may be transmitted to the quality evaluation module 500 without passing through the quality factor extractor 330 using an application programming interface (API). In this case, the third verification tool unit 315 may select verification data required by the quality evaluation module 500 from the calculated verification data and transmit the selected verification data to the quality evaluation module 500. Here, the selected verification data transmitted to the quality evaluation module 500 may be stored in the storage of the quality evaluation module 500. Here, the first verification tool 311 and the second verification tool 313 may also directly transmit verification data to the quality evaluation module 500 similarly to the third verification tool 315.

The quality factor extractor 330 extracts a quality factor from the verification data calculated by the verification performer 310. The quality factor extractor 330 may include at least one quality factor extractor (the first quality factor extractor 331 and the second quality factor extractor 333).

Each of the

quality factor extractors

331 and 333 may correspond one-to-one or one-to-many with the

verification tool units

311, 313, and 315 of the verification performer 310. That is, any one quality factor extractor may extract the quality factor using the verification data calculated by one verification tool unit of the verification performer 310, and another one quality factor extractor 310 may verify the verification factor 310. The quality factor may be extracted using the verification data calculated by the plurality of verification tool units.

Specifically, when the first verification tool unit 311 of the verification performer 310 is a code inspector and the first verification tool unit 311 outputs a predetermined calculation file, the first element of the quality factor extractor 330 The quality factor extractor 331 may extract a quality factor using a calculation file. In addition, when the second verification tool unit 313 of the verification performer 310 is a code inspector and the second verification tool unit 313 stores the verification data in the database, the second quality of the quality factor extractor 330 The element extractor 333 may extract the quality factor using the verification data stored in the database. An example of the quality elements extracted by the first or second quality

element extraction units

331 and 333 is shown in Table 1 below.

Table 1

ID	name	Availability
ID	name	project	file	function
41000	Severity Very High Count	O	O	X
41001	High Severity Count	O	O	X
41002	Low Severity Count	O	O	X
41003	Severity Very Low Count	O	O	X
41004	Severity Other Count	O	O	X

Table 1 above shows quality factors necessary to extract 'coding rule violation indicator values for each severity type', and the quality factors have IDs according to the severity type (very high, high, low, very low, etc.). Each ID has a predetermined value (number). In Table 1 above, availability indicates whether the corresponding ID can be used in project units, file units, and function units. Here, one project is composed of a plurality of files (source code files), and one file is composed of a plurality of functions.

If the ID 41000 is 5 in Table 1, it means that there are 5 critical coding errors in the project or file. Also, if ID 41001 is 10, it means that there are 10 major coding errors in the project or file.

Another example of the quality factor extracted by the first or second quality

factor extraction units

331 and 333 is shown in Table 2 below.

TABLE 2

ID	name	Availability
ID	name	project	file	function
11000	The number of test cases (TCs) with an Expected Value	O	O	O
11001	Number of TCs Tested Among TCs with Expected Value	O	O	O
11002	The number of passes among the TCs that contained the Expected Value and were tested	O	O	O

Table 2 above shows the quality factors needed to extract 'test coverage indicator values for requirements'.

4 is a detailed block diagram of the quality evaluation module 500 illustrated in FIG. 1.

Referring to FIG. 4, the quality evaluation module 500 may extract a comprehensive quality score by using quality factors received from the quality factor extraction module 300. The quality evaluation module 500 may include a quality index extractor 510, a quality feature extractor 530, and a quality score extractor 550.

The quality index extractor 510 may receive quality factors and extract quantitative quality index values for each quality index by using the received quality factors. The quality indicator value may be extracted by substituting a predetermined quality indicator into the received quality elements. Here, the quality index calculation formula may be a calculation formula predetermined by the user, or may be a formula predetermined by the software provider.

For example, when the quality indicator extractor 510 extracts the quality indicator value of the coding rule violation index by severity using the quality factors of Table 1, the quality index calculation formula of the coding rule violation indicator by the severity is Equation 1 below may be used. Here, the meaning of the coding rule violation index according to the severity is an indicator that can measure reliability through the number of coding rule violation items affecting the software. As the value of this indicator is larger, it is determined that the software has many potential errors and low reliability. Can be.

Equation 1

In Equation 1, M is a coding rule violation index value according to _severity , and NumOfViolation _severity is the number of violation items by type of severity. Here, the types of severities include severity very high (Major), severity (Major), low severity (Minor) and very low severity (Trivial). Critical means that an error correction is necessary because it has a very serious effect on the software, and Major means that error correction is strongly recommended because it can affect the software. Minor ) Means that error correction is recommended because it can affect the software. Very low Trivial means that error correction is recommended, although there is no significant effect on the software.

Equation 1 may be modified and changed by a software provider or by a user.

For another example, when the quality indicator extractor 510 extracts a quality indicator value of a test coverage indicator for a requirement using the quality factors of Table 2, the quality of the test coverage indicator for the requirement is determined. The quality index calculation formula may be Equation 2 below. Here, the meaning of the test coverage index for the requirement is an index for measuring the completeness of the verification request function by checking whether the test is performed on the requirement versus the requirement.

Equation 2

In Equation 2, CVR _req is a requirement coverage index value, NumOfReq _ExecutedTest is a number of requirements confirmed through test execution, and NumOfReq _Total is a total number of requirements.

Equation 2 may be modified and changed by a software provider or by a user.

The quality index extractor 510 may extract not only one quality index but also quality index values of each of the plurality of quality indexes. For example, the quality indicator extractor 510 not only the coding rule violation index value and the test coverage index value for the requirement as described above, but also the coding rule violation density index value and warning / error (Warning / Error). ), Complexity Indicator Value, MC / DC Effectiveness Indicator, Annotation Ratio Indicator Value, Effective Line Count Indicator Value, Conditional And / or Count Indicator Value, Function and Global Variable Count Indicator Value, State Coverage Indicator Values, branch coverage indicator values, MC / DC indicator values, calibration data coverage indicator values, module redistribution indicator values, multiple developer-managed function / module indicator values, portability check indicator values, portability checks List indicator values and resource efficiency check list indicator values can be extracted.

The coding rule violation density index is an index for measuring reliability through relative comparison with other software using the number of coding rule violation items per source code line. A lower value for this indicator means fewer potential errors in the software, which means higher reliability.

Warning / Error indicators are severity indicators for warnings and errors that occur when compiling software.

The complexity indicator is an indicator that shows the status of the complexity of each function. This indicator shows the ease of maintenance of the software based on the number of functions with function complexity above the allowable value.

The MC / DC validity index is an index capable of confirming the status of validity results for each function of MC / DC. This indicator shows the ratio of test cases that satisfy the MC / DC of all Boolean expressions in the function and test cases that satisfy the MC / DC of all branch conditional expressions in the function. By measuring, the ease of maintenance of the software can be confirmed.

Annotation rate index is an indicator that can check the status of the rate of annotations included in each file of the software. This indicator helps to verify the ease of maintenance of the software by checking whether the percentage of comments used to describe the contents of each file and function is sufficient. It can have a value of 0% when no comment is written, a value of 100% if the comment is written in the same amount as the source, and a value of 100% or more if more comments are written than the source.

The effective number of lines index is an index which can confirm whether or not the limit of valid lines is violated except for blank lines and comments for each function. Through this indicator, software maintainability can be confirmed by using the limited number of valid lines evaluation criteria to check whether the number of valid lines for each function is violated.

The and / or number index of the conditional expression is an index capable of confirming whether the number of and / or conditions of each conditional expression in the function exceeds the limit number. Increasing the number of and / or conditions in each conditional expression in a function can reduce the intelligibility of the source code, making the software less understandable.

The number of arguments and global variable index for each function is an index about the number of function arguments and the number of global variables. A large number of arguments and a global variable of a function means that a large number of software variables are used to cause an error.

The state coverage indicator is an indicator for measuring reliability by measuring the quality of the software test by checking the state of the state coverage. Larger values of this indicator indicate that the software has been adequately validated, which means higher reliability.

The Branch Coverage Index is an indicator for measuring reliability by measuring the quality of software tests by checking the status of branch coverage. Larger values of this indicator indicate that the software has been adequately validated, which means higher reliability.

The MC / DC index is an index for measuring reliability by measuring the quality of software tests by checking the MC / DC status. Larger values of this indicator indicate that the software has been adequately validated, which means higher reliability.

The calibration data coverage indicator is an indicator that can confirm the designed memory usage by checking the size and maximum usage of the calibration memory area. By checking this indicator, you can verify that you have a good design and that a sufficient resource usage test has been performed.

The redistribution index of modules is an indicator that can confirm the status of redistribution of major modules. This indicator can be used to identify violations of a given process for activities that exceed the limited number of module redistributions.

The multiple developer management function / module indicator is an indicator that can determine whether a change in function or module is caused by multiple developers. If multiple developers make changes to a specific function and module at the same time, it may be unintentionally reflected, so this indicator can confirm this.

The portability check index is an index for checking the change history of files that should not be changed. This metric allows you to measure the portability of your software by checking for modifications to files that should not occur.

The portability check list indicator is an indicator capable of confirming a positive response rate in an evaluation check list related to portability quality characteristics. The response of the check list is entered directly by the user.

The resource efficiency check list indicator is an indicator that can confirm the positive response rate in the evaluation check list considering the resource efficiency of the software. The response of the check list is entered directly by the user.

In order to extract each of the various quality indicator values mentioned above, the necessary quality factors and the quality indicator calculation formula are preset by the software provider or the user.

The quality characteristic extractor 530 receives a plurality of quality indicators extracted from the quality indicator extractor 510 and quality indicator values for the quality indicators, and groups the received quality indicators according to a preset condition. Create quality attribute groups. Here, the preset condition may be determined by a software provider or a user. As a specific example, referring to Table 3 below, the preset condition may include a plurality of quality indicators including a static quality characteristic, a dynamic quality characteristic, and a process quality characteristic. May be grouped together.

TABLE 3

Quality characteristics (a, b) a: second weight when a project, b: second weight when a file	Quality indicators (c, d) c: first weight in the project d: first weight in the file
Static (40%, 60%)	Coding rule violation indicators by severity (12%, 15%) 2. Coding Rule Violation Density Index (12%, 15%) 3. Warning / Error Indicator (11%, none) 4. Complexity indicators (15%, 15%) 5. MC / DC effectiveness indicators (10%, 15%) 6. Tin ratio indicator (10%, 15%) 7. Effective Line Count Indicator (10%, none) 8. And / or number indicators in conditional expressions (10%, 15%) 9. Number of arguments and global variables by function (10%, 10%)
Dynamic (30%, 40%)	Test Coverage Indicators for Requirements (25%, none) 2. State coverage indicators (10%, 30%) 3. Branch coverage indicators (20%, 30%) 4. MC / DC indicators (20%, 40%) 5. Calibration Data Coverage Metrics (25%, none)
Process (30%, none)	Redistribution index of modules (20%, none) 2. Multiple developer managed function / module metrics (20%, none) 3. Portability check indicator (20%, none) 4. Portability Checklist Indicators (20%, none) 5. Resource Efficiency Checklist Indicators (20%, none)

The quality characteristic extractor 550 groups a plurality of quality indicators as shown in Table 3, and then assigns a predetermined weight (first weight) to quality indicator values of each of the quality indicators in each group.

Specifically, as shown in Table 3, the first weight is assigned to each of the nine quality indicator values in the static quality characteristic, the first weight is assigned to each of the six quality indicator values in the dynamic quality characteristic, and the process quality characteristic. A first weight is assigned to each of the five quality indicator values in the.

As shown in Table 3, the first weight may be set to different values depending on the case of the project and the case of the file. For example, the first weight of the coding rule violation indicator value for each severity may be set to 12% in the project, and the first weight of the coding rule violation indicator value for each severity may be set to 15% in the project.

The first weight is a value preset by the software provider or the user, and is not limited to Table 3 above. The first weight may be changed to various values by the software provider or the user.

The quality characteristic extractor 550 assigns a first weight to each of the quality index values, and then extracts a quantitative quality characteristic value.

If a specific example is described with reference to Table 3 above, if the number 1 index value of the static quality characteristics is 90, the value 2 is 100, the value 3 is 90, the value 4 is 100, 5 If the value of the indicator is 100, the number 6 is 100, the value of the number 7 is 100, the value of the number 8 is 100, the value of the number 9 is 100, the value of the static quality characteristic is 97.7 (= (value of the number 1) * ( First weight) + ... ... + (index 6) * (first weight).

The quality score extractor 550 receives the plurality of quality characteristic values extracted by the quality characteristic extractor 530, and assigns a predetermined weight (second weight) to each of the received quality characteristic values.

Specifically, as shown in Table 3, the second weight (40%) is assigned to the static quality characteristic value, the second weight (30%) is assigned to the dynamic quality characteristic value, and the third quality is assigned to the process quality characteristic value. Weight (30%).

As shown in Table 3, the second weight may be set to different values depending on the case of the project and the case of the file. For example, the second weight of the static quality characteristic value in the project may be set to 40%, and the second weight of the static quality characteristic value in the file may be set to 60%.

Here, the second weight is a value preset by the software provider or the user, and is not limited to Table 3 above. The second weight may be changed to various values by the software provider or the user.

The quality score extractor 550 assigns a predetermined weight (second weight) to each of the received quality characteristic values, and then extracts a quantitative comprehensive quality score.

For example, referring to Table 3 above, if the static quality characteristic value is 97.7, the dynamic quality characteristic value is 98.4, and the process quality characteristic value is 96.4, the overall quality score is 97.52 (= (static quality characteristic value). ) * (Second weight) + (dynamic quality characteristic value) * (second weight) + (process quality characteristic value) * (second weight).

When the comprehensive quality score is extracted by the quality score extractor 550, the extracted comprehensive quality score is transmitted to the display module 700 illustrated in FIG. 1, and the display module 700 is received from the quality score extractor 550. The integrated quality score can be displayed to a user on a display device such as a monitor.

5 to 8 illustrate examples in which a quality score is displayed on a display device for each project or file.

5 is a window showing a project list, in which project 001 and project 002 are displayed in the window. For each project, the date of creation, the latest round, the quality assessment model, and the overall quality score are listed and a graph of the change over time of the overall quality score is shown.

FIG. 6 is a window showing specific information of any one project of FIG. 5, in which a comprehensive quality score, a file list, and a quality index list are described.

7 to 8 are windows showing a list of one of a plurality of files of a project and a specific comprehensive quality score.

Referring to FIG. 9, the quality control method according to the embodiment may include a quality element extraction step S100, a quality evaluation step S300, and a quality score display step S500.

The quality factor extraction step S100 extracts a quality factor from a source code file of software. The extraction method of the quality factor will be described in detail with reference to FIG. 10.

The quality evaluation step S300 extracts a quality score using the quality elements extracted in step S100. A method of extracting the quality score will be described in detail with reference to FIG. 11.

The quality score display step S500 displays the quality score extracted in step S300 on a display device such as a monitor.

FIG. 10 is a flowchart illustrating the quality factor extraction step S300 illustrated in FIG. 9.

Referring to FIG. 10, the quality factor extraction step S300 may include a source code verification step S310 and a quality factor generation step S330.

The source code verification step S310 verifies the input source code file using at least one verification tool. Specifically, the input source code file may be verified using a code inspector, a controller tester, a compiler, and other verification tools.

When the source code verification step S310 is performed, predetermined verification data are calculated according to each verification tool. The calculated verification data may be output as a calculation file as shown in FIG. 3 or may be stored in the database DB.

Meanwhile, the verification data calculated in the source code verification step S310 is not output to a calculation file or stored in a database, and some predetermined verification data may be directly used as a quality factor. The quality element is transmitted to the quality evaluation module 500 of FIG. 4 through an API (Application Programming Interface), and can be immediately used in the quality evaluation step S500 of FIG. 5.

The quality factor generation step S330 generates a quality factor from the verification data calculated in step S310. In detail, when the verification data calculated in operation S310 is output in the form of a calculation file, a quality factor may be generated by selecting some verification data from the calculation file. Here, the selected verification data may be data required in the quality evaluation step S500.

For example, the quality factor generation step S330 may generate a quality factor as shown in Table 1 above from verification data related to the severity of the source code.

FIG. 11 is a flowchart illustrating the quality evaluation step S500 illustrated in FIG. 9.

Referring to FIG. 11, the quality evaluation step S500 may include a quality index extraction step S510, a quality characteristic extraction step S530, and a quality score extraction step S550.

The quality index extraction step S510 extracts a quantitative quality index value for each quality index by using the quality elements output in the quality element generation step S330 of FIG. 10. The quality index value may be extracted by substituting the received quality factors into a predetermined quality index calculation equation. Here, the quality index calculation formula may be a calculation formula predetermined by the user, or may be a formula predetermined by the software provider.

As an example of extracting the quality indicator, the quality factors of Table 1 may be quantitatively extracted using Equation 1, and the quality factors of Table 2 may be extracted. Equation 2> can be used to extract quantitative quality indicator values.

There may be one quality indicator or a plurality of quality indicators. For example, quality metrics include coding rule violation indicators by severity, coding rule violation density indicators, warning / error indicators, complexity indicators, MC / DC validity indicators, annotation rate indicators, valid line count indicators, and conditional expressions. and / or count indicators, function and global variable count indicators, test coverage indicators for requirements, state coverage indicators, branch coverage indicators, MC / DC indicators, calibration data coverage (Calibration Data Coverage) indicators, module redistribution indicators, multiple developer management function / module indicators, portability check indicators, portability check list indicators, and resource efficiency check list indicators.

The quality characteristic extraction step S530 generates a plurality of quality characteristic groups by grouping the plurality of quality indicators extracted in the above step S510 according to a preset condition. Then, a predetermined weight (first weight) is assigned to each of the quality indicators in each group. Then, the quantitative quality characteristic values of each group are extracted. The detailed description is replaced with the above <Table 3> and the description thereof.

The quality score extraction step S550 extracts a quantitative comprehensive quality score by assigning a predetermined weight (second weight) to each of the plurality of quality characteristic values extracted in the above step S530. The specific method is replaced with the description of the quality score extraction method described in the above quality score extraction unit 550.

The above-described embodiments may be embodied in the form of program instructions that can be executed by various computer components and recorded on a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc. alone or in combination. Program instructions recorded on the computer-readable recording medium may be those specially designed and configured for the present invention, or may be known and available to those skilled in the computer software arts. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical recording media such as CD-ROMs, DVDs, and magneto-optical media such as floptical disks. optical media) and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device may be configured to operate as one or more software modules to carry out the process according to the invention, and vice versa.

The present invention described above is capable of various substitutions, modifications, and changes without departing from the technical spirit of the present invention for those skilled in the art to which the present invention pertains. It is not limited by the drawings.

Claims

In the quality factor extraction module for extracting the quality factor used in the quality evaluation module of the software,

A verification performer for verifying source code to extract verification data; And

A quality factor extractor for extracting the quality factor from the extracted verification data;

Including, the quality factor extraction module of the software.
The method of claim 1,

The verification performer includes a plurality of verification tools,

The quality factor extractor includes a plurality of quality factor extractors,

Wherein the plurality of verification tool units and the plurality of quality element extractors correspond one-to-one or one-to-many.
The method of claim 2,

Wherein each of the plurality of verification tool units calculates the verification data and outputs the calculated verification data as one calculation file.
The method of claim 2,

Each of the plurality of verification tool units calculates the verification data and stores the calculated verification data in a database.
In the quality factor extraction module for extracting the quality factor used in the quality evaluation module of the software,

Includes a verification performer to verify the source code,

The verification performer comprises at least one verification tool for extracting verification data from the source code,

And the verification tool unit transmits some verification data previously promised in the verification data to the quality evaluation module through an application programming interface (API).
In the quality factor extraction method for extracting the quality factor used in the quality evaluation module of the software,

A source code verification step of verifying the source code and extracting verification data; And

A quality factor generation step of extracting the quality factor from the extracted verification data;

Including, the quality factor extraction method of the software.
The method of claim 6,

The performing of the source code verification may include extracting the verification data from the source code using a verification tool,

Outputting the extracted verification data as a calculation file.
The method of claim 6,

The performing of the source code verification may include extracting the verification data from the source code using a verification tool,

And storing the extracted verification data in a database.
In the quality factor extraction method for extracting the quality factor used in the quality evaluation module of the software,

A source code verification step of verifying the source code and extracting verification data; And

A transmission step of transmitting some verification data previously promised in the verification data to the quality evaluation module through an application programming interface (API);

Including, the quality factor extraction method of the software.
A computer-readable recording medium having recorded thereon a program for executing a method for extracting quality elements of software according to any one of claims 6 to 9.