JPH07160495A - Source code evaluation device - Google Patents

Abstract

PURPOSE:To easily and speedily evaluate the quality of software even in decentralized development environment, to make the transmission speed of information regarding the quality fast, and to speedily cope with problem points of the quality. CONSTITUTION:An information gathering part 11 gathers the source codes of a program constituting a system to be evaluated from respective terminals 7. A quality metrics value measurement part 21 measures the quality metrics values of the source codes. On the basis of the measured quality metrics values, a system quality evaluation part 22 evaluates the quality of the evaluated system. According to the system evaluation result, a dangerous program extraction part 23 extracts a dangerous program which may cause trouble with high possibility. An information feedback part 12 feeds the evaluation result and the degree of danger of the program back to the respective terminals 7.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an apparatus for improving the quality of software by collecting quality data during software development (particularly in the process of programming) and feeding back the results in real time. In particular, it relates to a source code evaluation device for evaluating the source code of a software system developed in a distributed development environment.

[0002]

2. Description of the Related Art In software development, it is important to secure quality in each process, and various techniques for improving the quality have been considered in each process. It is well known that by evaluating the quality of the software for each process in this way, it is possible to detect errors in early processes, eliminating the need for backtracking work, leading to a reduction in development man-hours.

[0003] Generally, as a software quality evaluation method, a method of evaluating using quality metrics is known. Here, the quality metric is a measure prepared for understanding the quality of software from various viewpoints such as functionality, reliability, and maintainability, and the source code of software such as the number of steps and the number of conditional branches. A typical scale is the one targeted at, but other scales such as the number of documents and the number of functions have been proposed. Then, the quality of software is evaluated by measuring the value of such quality metrics.

[0004]

However, when the above-mentioned quality control using quality metrics is applied to an actual software development line, the following problems will occur.

1) The quality metric value is measured for each process and the quality is evaluated, which complicates the development work. That is, the development time of each process becomes long, and the work burden on the developer itself increases. In addition, there is a problem that the cost is high. That is, there is a trade-off between cost reduction due to quality improvement and cost increase for quality evaluation, and it becomes difficult to reduce cost in software development.

2) It is difficult to decide which quality metric to use among the many quality metrics.
That is, since the quality metrics suitable for quality evaluation differ depending on the type and content of the software, usage, operating conditions, etc., it is necessary to select the metrics on a case-by-case basis. Therefore, the development work becomes more complicated.

3) It is difficult to determine the evaluation standard.
That is, even if the quality metric is determined in 2) above, the evaluation criteria such as what the value should be, again depends on the type and content of the software, the usage, the operating conditions, etc. Alternatively, it is necessary to set evaluation criteria for each project. Therefore, the development work becomes more complicated.

[0008] In particular, when a software system is developed in a distributed development environment consisting of a plurality of terminals, it is difficult to smoothly transmit information regarding quality, and it is difficult to grasp the quality of the entire system. Information feedback is also delayed, and response to quality problems tends to be delayed.

The present invention has been proposed in order to solve the above-mentioned conventional problems, and an object thereof is to easily and quickly perform software quality evaluation even in a distributed development environment. It is an object of the present invention to provide an excellent source code evaluation device which has a high transmission speed of quality information and can quickly deal with quality problems.

[0010]

A source code evaluation device according to claim 1 is a source code evaluation device for evaluating a source code of software developed in a distributed development environment consisting of a plurality of terminals. , Quality metric value measuring means, system quality evaluation means, dangerous program extraction means, and information feedback means.

Of these, the information collecting means is means for collecting the source code of the program being developed and the information on the trouble that has occurred from each terminal in which the program making up the system to be evaluated is being developed. The quality metric value measuring means is a means for measuring the value of the quality metric from the source code collected by the information collecting means. The system quality evaluation means is means for performing quality evaluation of the evaluation target system based on the quality metrics value obtained by the quality metrics value measuring means for the source code of the program forming the evaluation target system. The dangerous program extracting means is a means for extracting a dangerous program having a high possibility of causing a trouble based on the system evaluation result obtained by the system quality evaluation means. The information feedback means is means for feeding back the system evaluation result obtained by the system quality evaluation means and the risk program extraction means and the risk degree of the program to each of the terminals.

The source code evaluation device according to a second aspect of the present invention further comprises a system evaluation data file, a model system extraction means, and a system evaluation data change means in addition to the configuration of the first aspect. Is characterized by. Among these, the system evaluation data file is a means for storing the system evaluation data for performing the quality evaluation of the evaluation target system by the system quality evaluation means. The model system extracting means is a means for selecting a system to be a system evaluation model from the source codes collected by the information collecting means. The system evaluation data changing means analyzes the model system selected by the model system extracting means to determine a quality metric suitable for system evaluation, and the quality metric data is used for the system evaluation data file in the system evaluation data file. It is a means of changing data.

A source code evaluation device according to a third aspect of the present invention includes, in addition to the configuration of the first aspect, a program evaluation data file, trouble information display means, and program evaluation data change means. Is characterized by. Among these, the program evaluation data file is a means for storing the program evaluation data for extracting the dangerous program by the dangerous program extracting means. The trouble information display means is a means for displaying the relationship between the characteristics of the program and the number of troubles from the trouble information collected by the information collecting means. The program evaluation data changing means determines a quality metric suitable for dangerous program extraction based on the relationship displayed by the trouble information display means, and the data of the program evaluation data in the program evaluation data file is used by the quality metric data. Is a means to change.

[0014]

The operation of the source code evaluation apparatus of the present invention having the above construction is as follows.

1) It is possible to automatically collect the source code of a program constituting the evaluation target system from each terminal and automatically evaluate the quality, and then automatically feed back the obtained information. That is, the information collecting means automatically collects the source code of the program constituting the evaluation target system from each terminal, the quality metric value measuring means automatically measures the quality metric value, and the system quality evaluating means evaluates the quality metric value. The quality of the target system can be automatically evaluated, the dangerous program can be automatically extracted by the dangerous program extraction means, and the evaluation result and the degree of risk of the program can be automatically fed back to each terminal by the information feedback means. it can.

2) The system quality evaluation means makes it possible to evaluate the system to be evaluated as the entire system. That is, it is possible to relatively evaluate how much the quality is when compared with other systems.

3) By extracting the dangerous programs by the dangerous program extracting means, it is possible to narrow down the programs for which the code reviews and the test items are reviewed. In other words, by calculating the risk level of a program (possibly leading to trouble) and extracting only the high-risk programs as programs that need to be reviewed,
You can minimize the number of programs reviewed.

4) From the source code collected by the information collecting means, the past system to be a model for system evaluation can be selected by the model system extracting means. Then, the system evaluation data changing means analyzes the data of the past system to determine the quality metrics for system evaluation and the reference values thereof, and the data in the system evaluation data file is analyzed by this system evaluation data. Can be updated. In this way, by extracting the system evaluation data from the data of the past system, it is possible to perform the system evaluation suitable for the type and content of the evaluation target system, usage, operating conditions, and the like.

5) From the trouble information collected by the information collecting means, the trouble information displaying means presents the relationship between the characteristics of the program and the number of troubles to the user, so that the user is suitable for the dangerous program extraction. It is possible to easily determine the quality metric and its reference value. The program evaluation data determined by the user is registered in the program evaluation data file by the function of the program evaluation data changing means.

[0020]

【Example】

[1] Configuration of Embodiment An embodiment of the source code evaluation device according to the present invention will be specifically described below with reference to the drawings. Figure 1
FIG. 3 is a block diagram showing the configuration of the source code evaluation apparatus of this embodiment, which comprises a host 6 and a plurality of terminals 7. The configuration of the host 6 is 5 as "information transmission unit 1", "quality evaluation unit 2", "system evaluation data file changing unit 3", "program evaluation data file changing unit 4", and "database 5". It is roughly divided into two functional parts. In addition, thick and thin arrows connecting the respective functional units respectively indicate a main data flow and a sub data flow between the functional units. First, the configurations of the five functional units 1 to 5 will be sequentially described below.

[1-1] Information Transmission Unit 1 The information transmission unit 1 is a unit for exchanging information between the host 6 and each terminal 7, and includes the "information collection unit 11" and the "information feedback unit 12". It is configured. this house,
The information collecting unit 11 collects the information of each terminal 7 and stores the information in the database 5 (program source code file 5
1 and a trouble information file 53) are functional units for storing information. The information feedback unit 12 is a functional unit that sends the quality evaluation result of the quality evaluation unit 2 to each terminal 7.

[1-2] Quality Evaluation Unit 2 The quality evaluation unit 2 is the core of the source code evaluation device, and includes a "quality metric value measurement unit 21", a "system quality evaluation unit 22", and a "system quality evaluation unit 22". The risk program extraction unit 23 "is included. Among these, the quality metric value measuring unit 21 is a functional unit that reads the source code of the program forming the evaluation target system from the database 5 (program source code file 51) and measures the value of the quality metric. In addition, the system quality evaluation unit 22 evaluates the quality of the evaluation target system from the measurement result of the metric value by the quality metric value measurement unit 21 and the system evaluation data stored in the database 5 (system evaluation data file 52). It is a functional unit that performs. Furthermore, the dangerous program extraction unit 23 leads to a trouble from the quality evaluation result of the evaluation target system by the system quality evaluation unit 22 and the data for program evaluation stored in the database 5 (data file 54 for program evaluation). This is a functional unit that extracts programs with a high possibility as dangerous programs.

[1-3] System Evaluation Data File Change Unit 3 The system evaluation data file change unit 3 is a functional unit for updating the system evaluation data in the database 5 (system evaluation data file 52). And is composed of a "model system extraction unit 31" and a "system evaluation data change unit 32". Of these, the model system extraction unit 31 is a functional unit that selects a model system (a good system and a bad system) from the systems stored in the database 5 (program source code file 51) up to that point. In addition, the system evaluation data changing unit 32 includes a model system extracting unit 31.
It is a functional unit that analyzes the model system extracted by, generates data necessary for system evaluation, and changes the contents of the database 5 (system evaluation data file 52).

[1-4] Program Evaluation Data File Change Unit 4 The program evaluation data file change unit 4 is a functional unit for updating the data for program evaluation in the database (program evaluation data file 54). Yes,
It is composed of a "trouble information display section 41" and a "program evaluation data changing section 42". Of these, the trouble information display unit 41 is collected by the information collecting unit 11 and stored in the database 5 (trouble information file 53), and the quality evaluation unit 2 generates the trouble information, and the database 5 (evaluation result file 55). It is a functional unit that displays to the user the relationship with the evaluation results stored in. In addition, the program evaluation data changing unit 42 includes a trouble information display unit 4
When the user judges whether to change the program evaluation data with respect to the display of 1 and judges that the change is necessary and inputs the changed contents, the database 5 (program evaluation data file 54) is displayed. It is a functional unit that accesses and changes data.

[1-5] Database 5 The database 5 includes "program source code file 51", "system evaluation data file 52", "trouble information file 53", "program evaluation data file 54", and "evaluation". Result file 55 ". Among them, the program source code file 51 stores the source code of the program collected from each terminal 7 by the information collecting unit 11. Further, the system evaluation data file 52 stores data for system evaluation. Here, the data used as the basis for system evaluation is composed of two models, a good system model and a bad system model. Further, the trouble information file 53 stores the trouble information of the programs collected from each terminal 7. On the other hand, the program evaluation data file 54 stores data for program evaluation. The evaluation result file 55 stores the result of the quality evaluation by the quality evaluation unit 2.

[2] Operation of the Embodiment Next, the operation of the source code evaluation apparatus of this embodiment having the above-mentioned configuration will be described.

[2-1] Flow of processing in each functional unit First, the flow of processing in each functional unit will be described with reference to individual flowcharts.

[2-1-1] Process Flow of Information Collection Unit 11 FIG. 2 is a flowchart showing the process flow of the information collection unit 11. First, the information collecting unit 11 issues an instruction to each terminal 7 to send information at the designated time (step 11-1). Specifically, the information collecting unit 11 is set with an appropriate date and fixed time. In this case, the format for setting the date is to set the first date, the date interval, and the last date, such as from what day of the month to every second day of every month, or what day of the month. Various formats can be used, such as a format in which multiple dates are individually set, such as and what day.

Next, the information collecting unit 11 confirms whether or not there is a response from all the terminals 7 at the designated information collecting time (step 11-2). Here, the response content from the terminal 7 differs depending on the presence or absence of new information. That is, if there is newer information than the previously sent information, the new information is sent, and if there is no new information, the fact is notified. Then, when there is a terminal 7 that does not respond, the information collecting unit 11
If there is new information, an instruction is issued to send that information (step 11-3).

By the above processing, when all the terminals 7 have been contacted, the information collecting section 11 confirms whether or not the new source code is sent as information (step 11-4). If new source code is sent, this source code is stored in the program source code file 51 (step 11-
5). Next, the information collecting unit 11 confirms whether new trouble information has been sent (step 11-6).
Then, when new trouble information is sent, this trouble information is stored in the trouble information file 53 (step 11-7).

[2-1-2] Information feedback section 12
Process Flow of FIG. 3 is a flowchart showing a process flow of the information feedback unit 12. First, the information feedback section 1
2 reads the evaluation result of the source code of the program forming the evaluation target system from the evaluation result file 55 (step 12-1). Next, the information feedback unit 12 sends the read evaluation result to each terminal 7 (step 12-2).

[2-1-3] Quality metric value measuring unit 2
Process Flow of No. 1 FIG. 4 is a flowchart showing a process flow of the quality metric value measuring unit 21. First, the quality metric value measuring unit 21 sets the source code of the program that constitutes the evaluation target system to the program source code file 51.
Is read from (step 21-1). Next, the quality metric value measuring unit 21 uses the system evaluation data file 5
The quality metrics for system evaluation are read from 2 (step 21-2). Then, the quality metric value measuring unit 2
1 measures the quality metrics value of the source code of each read program (step 21-3). Finally,
The quality metric value measurement unit 21 passes the measurement result to the system quality evaluation unit 22 (step 21-4).

[2-1-4] Process Flow of System Quality Evaluation Unit 22 FIG. 5 is a flowchart showing the process flow of the system quality evaluation unit 22. First, the system quality evaluation unit 22
Reads the quality metrics used for system evaluation and their respective reference values from the system evaluation data file 52 (step 22-1). Next, the system quality evaluation unit 22 compares the read reference value with the measured metric value (step 22-2), and gives the system an evaluation for each metric (step 22-3). Subsequently, the system quality evaluation unit 22 summarizes the evaluation results for each metric for the system for each viewpoint (step 22-
4) The system evaluation result for each viewpoint is passed to the dangerous program extracting unit 23 together with the metric value measured by the quality metric value measuring unit (step 22-5). Here, the viewpoint means a group of metrics in several groups. For example, the grouping in which the metrics such as the number of steps and the number of data belong to the group of “size” is considered.

[2-1-5] Danger program extraction unit 23
FIG. 6 is a flowchart showing the processing flow of the dangerous program extraction unit 23. First, the dangerous program extraction unit 2
3 reads the metrics used for program evaluation and their respective reference values from the program evaluation data file 54 (step 23-1). Next, the dangerous program extracting unit 23 compares the measured metric value with each other and gives each program an evaluation for each metric (step 23-2). Next, the dangerous program extraction unit 23 determines the degree of risk of each program (which may lead to trouble) from the result of the system evaluation for each viewpoint obtained by the system quality evaluation unit 22 in the previous stage and the evaluation result for each metric for each program. (Size of sex) is calculated (step 23-
3). Finally, the dangerous program extracting unit 23 stores the evaluation result such as the system evaluation result, the value of each metric, and the degree of risk in the evaluation result file 55 (step 23-4).

[2-1-6] Model system extraction unit 31
Process Flow of FIG. 7 is a flowchart showing a process flow of the model system extraction unit 31. In the source code evaluation apparatus of the present embodiment, the system evaluation reference data stored in the system evaluation data file 52 is composed of two models, a good system model and a bad system model, as described above. Has been done. First, the model system extraction unit 31 determines whether to replace a model of a good system (step 31-1). When exchanging the model of the good system, the model system extraction unit 31 selects the model of the good system from the program source code file 51 and reads it (step 31-2). Next, the model system extraction unit 31 determines whether or not to replace the model of the bad system (step 31-3).
When exchanging the model of the bad system, the model system extraction unit 31 selects the model of the bad system from the program source code file 51 and reads it (step 31-4). Finally, the model system extraction unit 31
Passes the read source code of the system to the next system evaluation data changing unit 32.

[2-1-7] Process Flow of System Evaluation Data Change Unit 32 FIG. 8 is a flowchart showing the process flow of the system evaluation data change unit 32. First, the system evaluation data changing unit 32 causes the quality metrics value measuring unit 21 to read the quality metrics list from the system evaluation data file 52 (step 32-1). next,
The system evaluation data changing unit 32 causes the quality metric value measuring unit 21 to measure the metric value of each program that constitutes a good system model (step 3).
2-2) Similarly, the quality metric value measuring unit 21 measures the metric value of each program forming the model of the bad system (step 32-3).

Next, the system evaluation data changing unit 32
Is from the measurement result by the quality metric value measuring unit 21,
For each metric, it is tested whether there is a difference between the mean value of the model of the good system and the mean value of the model of the bad system (step 32-4). Here, the test means to examine from a statistical point of view. That is, when investigating whether there is a difference in the average values, it cannot be said that there is a difference in the average values of the two systems immediately because the average values are simply different due to the influence of the variance. , It means statistically examining whether or not there is a difference in average value with a certain degree of reliability. Generally, as the reliability, 99%, 95%, etc. are often selected, but here, it is assumed that the reliability of 99% is used. Finally, the system evaluation data changing unit 32 registers, in the system evaluation data file 52, a metric that is found to have a difference in average value with a reliability of 99% as a result of the test (step 32- 5).

[2-1-8] Process Flow of Trouble Information Processing Unit 41 FIG. 9 is a flowchart showing the process flow of the trouble information display unit 41. First, the trouble information processing unit 41
Reads the trouble information from the trouble information file 53 (step 41-1), and then the evaluation result file 5
The evaluation result is read from 5 (step 41-2). Then, the trouble information processing section 41 displays the relationship between the degree of danger of each program and the trouble information from the read evaluation result and trouble information (step 41-3). With this display, the user can determine whether or not the risk level calculation formula at that time (including the viewpoint weighting setting) is valid. Finally, the trouble information display unit 41 displays the relationship between each metric value and the trouble information based on the read evaluation result and trouble information (step 41-4).
From this display, the user can determine whether the setting of the reference value of each metric value at that time is appropriate.

[2-1-9] Process Flow of Program Evaluation Data Change Unit 42 FIG. 10 is a flowchart showing the process flow of the program evaluation data change unit 42. First, the program evaluation data changing unit 42 activates an editor for rewriting the data of the program evaluation data file 54 to allow the user to rewrite (step 42).
-1). Thereby, the user can input the change contents when it is determined that the change is necessary from the display by the trouble information display unit 41 described above. Next, the program evaluation data changing unit 42 determines whether to change the program evaluation data based on the input by the user (step 42-2). When the data is changed, that is, when the change data is input, the program evaluation data change unit 42 rewrites the data of the program evaluation data file 54 with the input change data (step 42- 3).

[2-2] Overview of Processing of Entire Device In the above description, the flow of processing in each functional unit has been individually described. Next, the processing of the entire source code evaluation device of this embodiment will be described. The outline will be described with reference to the flowchart of FIG.

[2-2-1] Program Evaluation Processing First, it is determined whether or not to perform program evaluation (step 100-1). When performing the program evaluation, the information collecting unit 11 collects information from the terminal 7 (step 1
00-2), the quality metric value measurement unit 21 measures the value of the quality metric (step 100-3), and the system quality evaluation unit 22 evaluates the entire system (step 100-4). Next, the dangerous program extracting unit 23 extracts the dangerous program (step 100-
5) The information feedback unit 12 feeds back information about the evaluation result to the terminal 7 (step 100).
-6). Then, it is judged whether or not the evaluation period of the program has ended (step 100-7), and if the evaluation period has not ended, the process returns to step 100-2 again,
If the evaluation period has ended, the processing ends.

[2-2-2] System Evaluation Data Change Processing If the program evaluation is not performed in step 100-1, it is determined whether the system evaluation data is changed (step 100- 8). When the system evaluation data is changed, the model system extraction unit 31 determines the model system (step 100-
9). Next, by the system evaluation data changing unit 32,
Extract metrics suitable for system evaluation (Step 1
00-10), the data in the system evaluation data file 52 is changed (step 100-11), and the process is terminated.

[2-2-3] Program Evaluation Data Change Processing Further, if the system evaluation data is not changed in step 100-8, it is determined whether or not the program evaluation data is changed (step 100). -12). When changing the program evaluation data, the trouble information display unit 41 examines the relationship between the trouble information, the degree of danger, and each metric value, and shows it to the user (step 100-13).
When the user inputs the change data, the program evaluation data changing unit 42 determines that the change is necessary, changes the data of the program evaluation data file 54 (step 100-14), and ends the process. To do.

[2-3] Source Code Evaluation Processing of Office Processing Program Next, the quality evaluation processing of the office processing program is actually realized on the multi-window computer by using the source code evaluation apparatus of this embodiment. The flow of processing in that case will be specifically described.

First, the source code evaluation apparatus of this embodiment is activated by the activation menu as shown in FIG. This menu has three selection items, "program evaluation", "system evaluation data change", and "program evaluation data change". In this menu, the user can select the desired processing by clicking any one of the three selection items.

[2-3-1] Setting of program automatic execution file When the user selects "program evaluation" in the menu of FIG. 12, a program automatic execution file screen as shown in FIG. 13 is displayed. To be done. This automatic execution file has three types of setting items: a "system name" to be evaluated, an "evaluation date" to carry out the evaluation, and a "terminal name" in which a program constituting the evaluation target system is developed. When the user sets the necessary data for this automatic execution file screen, this source code evaluation device collects the necessary information from the specified terminal on the specified evaluation date, and automatically Will be able to evaluate the program. In other words, after setting this file, the program will be evaluated automatically, and the system quality will be evaluated and the dangerous program will be extracted at the specified evaluation date without the need for the user to do any work. Then, the evaluation result is sent to each terminal.

[2-3-2] Program Evaluation Processing When the evaluation date comes, in the source code evaluation device, first, when the information collecting unit 11 collects information from the terminal 7 and there is a new source code, The source code is stored in the program source code file 51, and when there is new trouble information, the trouble information is stored in the trouble information file 53. Next, the quality metric value measuring unit 21 reads the source code of the program configuring the evaluation target system from the program source code file 51, and performs system evaluation from the system evaluation data file having the contents shown in FIG. A quality metric for a program is read, a metric value of the source code of each program is measured, and a measurement result as shown in FIG. 15 is obtained.

The quality metrics shown in FIG. 14 are classified into several viewpoints. From the viewpoint of size, the "number of steps" (the number of lines of the program) and "the maximum value of the length of one sentence" ( The maximum number of lines of one statement in a program), etc., and from the viewpoint of control structure, "the number of condition judgments per step" (how many condition judgments are made per line of the program), " Maximum nesting depth "(maximum depth of conditional branch hierarchy in the program), etc.
In addition, from the viewpoint of how the data is used, metrics such as “ratio of [substitution] and [reference] data” (how much of the data used for both [substitution] and [reference] among all data) Is used. Measurement of metric values is performed for all metrics defined here.

After the measurement of the metric value is completed, the system quality evaluation unit 22 reads the quality metric and the evaluation reference value from the system evaluation data file shown in FIG. 14, and measures each metric value with reference to the evaluation reference value. Evaluate. For example, regarding the metric of the number of steps, if the average value of the number of steps of the programs that configure the system is 500 or less, the evaluation is A (good), 5
If it is 00 to 700, the evaluation is B (reasonably good), 700 to
If it is 900, the evaluation is C (slightly good), and if it is 900 or more, the evaluation is D (bad).

It should be noted that the metrics used for such system evaluation are only those which are designated in advance in the system evaluation data file 52 for use in system evaluation (a part or all of the defined metrics). Therefore, it is necessary to set the reference value in advance.
The setting of this system evaluation data file is performed by "Change system evaluation data" in the start menu of FIG.
Can be performed by selecting. The method of change (how to select the metric used for system evaluation, how to set the reference value, etc.) will be described later.

After finishing the evaluation for each metric of the system as described above, the system quality evaluation unit 22 summarizes the evaluation results for each metric for each viewpoint as shown in FIG. As a way of summarizing, in the evaluation of the metrics included in each viewpoint, A (good) is 1 point, B (relatively good) is 2 points, C (slightly good) is 3 points, and D (bad) is 4 points and averaged. Take a value and round it to the nearest whole number. If the value is 1 point, the viewpoint is evaluated as A, B if 2 points, C if 3 points, and D if 4 points. For example, assuming that the metrics included in the viewpoint of size are two metrics, that is, the number of steps and the maximum value of the length of one sentence, and the evaluation of each metric is A or B, then in this case, the average The value is 1 + 2/2 = 1.5, which is 2 when rounded, so the evaluation in terms of size is B.

After the system quality evaluation unit 22 completes the system evaluation, the dangerous program extraction unit 23 reads the quality metrics and the evaluation reference value from the program evaluation data file as shown in FIG. 17 and calculates the risk.
The viewpoint weight in FIG. 17 is a scale indicating which viewpoint is emphasized when extracting a dangerous program, and in the case of default (when the viewpoint weight is not described), the viewpoint weight of each system is different. In the evaluation, the viewpoint of evaluation A is weight 1, evaluation B
Is set to have a weight of 2, the viewpoint of evaluation C has a weight of 3, and the viewpoint of evaluation D has a weight of 4. In other words, the weight of this viewpoint is used to calculate the degree of risk by emphasizing the viewpoint with poor evaluation.

Further, which metric is used for the program evaluation, and the larger the value of the metric, the less dangerous (the ascending order is defined as the degree of danger, and the value smaller than the reference value is set as zero). It is also specified in this program evaluation data file whether or not it is more dangerous (ranking in descending order is the degree of danger, and values greater than the reference value are zero). The higher the risk, the higher the danger, that is, the higher the possibility of trouble. The program evaluation data file can be changed by selecting "change program evaluation data" in the start-up menu of FIG. How to change will be described later.

Furthermore, the method of calculating the risk is as shown in FIG.
As shown in. That is, the weight from the viewpoint of size is α, the risk of each metric belonging to the viewpoint of size is X ₁ , X ₂ , X ₃ , ..., And the weight from the viewpoint of control structure is β. The risk of each metric belonging to the viewpoint of is defined as Y ₁ , Y ₂ , Y ₃ , ..., and the weight of the viewpoint of data usage is defined as γ, and the risk of each metric belonging to the viewpoint of data usage is defined as γ. The degree is Z ₁ , Z ₂ , Z ₃ , ...,
Then, the degree of risk is expressed by the following equation (1).

[0055]

[Equation 1] As described above, this degree of risk means that the larger the value, the more dangerous (the higher the possibility of causing a trouble). Therefore, the dangerous program extraction unit 23
Are extracted as dangerous programs in descending order of risk. After the calculation of the degree of risk, the dangerous program extraction unit 2
As shown in FIG. 19, the program 3 rearranges the programs constituting the evaluation target system in descending order of risk, and creates risk and metric values for each program as evaluation results. This FIG. 19 shows the evaluation results from the second time onward when the same system is evaluated, and shows how the direction of the arrow next to the metric value changes as compared with the previous evaluation result. Shows. That is, the upward arrow indicates that the value has increased from the previous time, the downward arrow indicates that the value has decreased from the previous time, and the horizontal arrow means that the value is the same as the previous time.

Further, the dangerous program extracting section 23 stores the program evaluation result obtained as described above in the evaluation result file 53. Then, the information feedback unit 12 reads the program evaluation result thus stored in the evaluation result file 53 and sends it to each terminal 7.

[2-3-3] System Evaluation Data Change Processing Next, a case where the user selects “change system evaluation data” in the menu of FIG. 12 will be described. This function is a function for updating the data necessary for system evaluation. First, when the user selects “change system evaluation data” in the menu of FIG. 12, a model system extraction screen as shown in FIG. 20 is displayed. On this screen, the user selects one of the good system model and the bad system model from the systems that have been stored as data so far. When the user clicks Yes in response to the question "Is it okay to set?" Displayed on the screen, the model system extraction unit 31 causes the source code of the program that constitutes the model of the selected system. Is read from the program source code file 51, and this source code is passed to the system evaluation data changing section 32.

Subsequently, the system evaluation data changing section 32
Automatically performs statistical processing from the source code of the good system model and the bad system model, and extracts the metrics that distinguish between the good system and the bad system. That is,
The system evaluation data changing unit 32 extracts, by a test, a metric that is recognized to have a difference in average value with a reliability of 99%. The data of the metrics extracted in this way is displayed as a system evaluation data file change screen as shown in FIG.

In the screen of FIG. 21, the metrics in the "old" column and the reference values for evaluation are the data used until the previous time, and the metrics in the "new" column and the reference values for evaluation are newly extracted this time. The data. Here, the evaluation reference value of the system evaluation metric is set as follows. That is, as shown in FIG. 22, when the metric value of the model of the good system is L and the metric value of the model of the bad system is M, these two values L and M are represented on a number line, and this number line The reference values for the evaluations A, B, C and D are determined based on the four equal points.

For example, in the case of a metric in which a smaller value is better, letting the value of the metric be X, "X≤L + (M
If -L) / 4, then evaluation A (good) "," L + (M-
If L) / 4 <X ≦ L + 2 × (ML) / 4, then evaluation B
(Reasonably good) "," L + 2 × (ML) / 4 <X ≦ L
If it is + 3 × (ML) / 4, the evaluation is C (a little better) ”,
“If X> L + 3 × (ML) / 4, the evaluation is D (bad)”. When registering a new metric and its evaluation standard value as shown in Fig. 21, the user clicks Yes to the question "Do you want to update the data file?" Displayed on the screen. By doing so, the system evaluation data changing unit 32 registers the new metric and its evaluation reference value in the system evaluation data file 52.

[2-3-4] Program Evaluation Data Change Processing Next, a case where the user selects "change program evaluation data" in the menu of FIG. 12 will be described. This function is a function for updating the data necessary for program evaluation. First, when the user selects “change program evaluation data” in the menu of FIG. 12, the trouble information display unit 41 reads the trouble information from the trouble information file 53 and the evaluation result from the evaluation result file 55. Next, the trouble information display unit 41 displays, from these data, a relationship display screen between the degree of danger of each program and the number of troubles as shown in FIG. 23, and a metric value and the number of troubles of each program as shown in FIG. Display the relationship display screen. The number of troubles in FIG. 23 and FIG. 24 is divided into three stages of large, medium, and small according to the degree of importance (the magnitude of the influence of the trouble), and the higher the degree of importance, the larger the trouble. Means

Further, as described above, the trouble information processing unit 4
At the same time that two screens are displayed by 1, the program evaluation data change unit 42 displays the program evaluation data file change screen as shown in FIG. 25, starts the editor, and allows the user to rewrite. To do. Further, the user refers to the two relationship display screens shown in FIGS. 23 and 24, and on the program evaluation data file change screen of FIG. 25, the weight of the viewpoint, the selection of the metric used for the program evaluation, and the degree of risk. , Various data such as reference value are changed as necessary. This change process is
In this source code evaluation device, it is the only process that changes the specific content of the evaluation data according to the user's judgment. When the changed data is registered, the user clicks Yes in response to the question “Are you sure you want to save?” Displayed on the screen, and the program evaluation data changing unit 42 causes the data to be changed. The program evaluation data file 54 is rewritten with the changed data.

[3] Effects of the Embodiment As described above, in the source code evaluation apparatus of this embodiment, first, the information collecting unit 11 supplies each terminal 7 with the source code of the program constituting the evaluation target system.
Can be automatically collected from. Next, the quality metric value measuring unit 21 automatically measures the quality metric value of the source code, the system quality evaluating unit 22 automatically evaluates the quality of the evaluation target system, and the dangerous program extracting unit 23 executes the dangerous program. It can be automatically extracted. Subsequently, the information feedback unit 12 provides the evaluation result and the degree of risk of the program to each terminal 7
Can be automatically fed back. Then, the following effects can be obtained from such an action.

1) Since the source code of the program that constitutes the evaluation target system can be automatically evaluated, the quality can be evaluated much easier and faster than before, and the user himself / herself can perform each step. There is no need to make a judgment for quality evaluation every time. Therefore, since the quality evaluation work by the user is unnecessary in this way, the entire software development work can be simplified and shortened compared to the conventional case, and the development efficiency of the entire software can be improved.

2) Even in a distributed development environment, it is possible to evaluate the evaluation target system as a whole system, and it is possible to automatically and quickly transmit information regarding quality. Therefore, since the quality of the entire system can be grasped quickly, it is possible to quickly deal with the problem of quality.

3) By extracting a dangerous program by the dangerous program extracting section 23, it is possible to narrow down the programs for which code reviews and test items are reviewed. Therefore, since the number of programs to be reviewed can be reduced as much as possible, the quality of the programs can be improved efficiently.

In the source code device of this embodiment, the model code is extracted from the source code collected by the information collecting section 11 and stored in the program source code file 51 and used as a model for system evaluation by the model system extracting section 31. System can be selected.
Then, the system evaluation data changing unit 32 analyzes the past system data to determine the system evaluation quality metric and the reference value thereof, and the system evaluation data file 5 is used by the system evaluation data.
The data in 2 can be updated. Further, in the present embodiment, the following effects are further obtained from such an action.

4) Since the system evaluation data can be automatically extracted from the data of the past system, the system evaluation data is a system suitable for the type, content, use, operating conditions, etc. of the system to be evaluated. An evaluation can be done. Further, the user only has to select an appropriate system in the past as a model, and is not bothered to decide the system evaluation data.

Furthermore, in the source code device of this embodiment, from the trouble information collected by the information collecting unit 11 and stored in the trouble information file 53,
The trouble information display unit 41 can present the relationship between the characteristics of the program and the number of troubles to the user. Then, the program evaluation data determined by the user can be registered in the program evaluation data file 54 by the function of the program evaluation data changing unit 42. And in this embodiment,
From such an action, the following effects are further obtained.

5) By presenting the relation between the characteristics of the program and the number of troubles to the user, the user can
By referring to the presented relationship, it is possible to easily determine the quality metric suitable for the risk program extraction and its reference value.

[4] Other Embodiments The present invention is not limited to the above embodiments, and for example, the processing flow of each functional unit and the specific contents of individual processing can be changed as appropriate. Is. Further, the type of software to be evaluated can be freely selected, and the quality metric used as the evaluation data and its reference value change depending on the type of software. Furthermore, the implementation form of each means constituting the present invention can be freely selected.

[0072]

As described above, in the present invention, the system to be evaluated is configured by using the information collecting means, the quality metric value measuring means, the system quality evaluating means, the dangerous program extracting means, and the information feedback means. It is possible to automatically collect the source code of the program to be performed from each terminal, automatically evaluate the quality, and then automatically feed back the obtained information. Therefore, even in a distributed development environment, it is possible to easily and quickly evaluate software quality, the transmission speed of quality information is high, and an excellent source that can quickly deal with quality problems A code evaluation device can be provided.

[Brief description of drawings]

FIG. 1 is a block diagram showing the configuration of an embodiment of a source code evaluation device according to the present invention.

FIG. 2 is a flowchart showing the flow of processing of an information collecting unit 11 of FIG.

FIG. 3 is a flowchart showing a processing flow of an information feedback unit 12 of FIG.

FIG. 4 is a flowchart showing a processing flow of a quality metric value measuring unit 21 of FIG.

5 is a flowchart showing a processing flow of a system quality evaluation unit 22 of FIG.

FIG. 6 is a flowchart showing a processing flow of a dangerous program extracting section 23 in FIG.

7 is a flowchart showing the flow of processing of a model system extraction unit 31 in FIG.

8 is a flowchart showing a processing flow of a system evaluation data changing unit 32 in FIG.

9 is a flowchart showing a processing flow of a trouble information display section 41 of FIG.

10 is a flowchart showing a processing flow of a program evaluation data changing unit 42 in FIG.

11 is a flowchart showing an outline of processing of the entire source code evaluation apparatus of FIG.

FIG. 12 is an explanatory diagram showing an example of a start-up menu for starting up the source code evaluation device of FIG. 1.

13 is an explanatory diagram showing an example of a file screen for automatic execution of a program displayed by the source code evaluation device in FIG.

14 is an explanatory diagram showing an example of the contents of a system evaluation data file 52 of FIG.

FIG. 15 is an explanatory diagram showing an example of a measurement result of a metric value by a quality metric value measuring unit 21 in FIG.

16 is an explanatory diagram showing an example of a system evaluation result by the system quality evaluation unit 22 of FIG.

17 is a program evaluation data file 54 of FIG.
Explanatory diagram showing an example of the content of.

18 is an explanatory diagram showing an example of a method of calculating a risk degree by the risk program extracting section 23 of FIG. 1. FIG.

FIG. 19 is an explanatory diagram showing an example of an evaluation result output by the dangerous program extraction unit 23 of FIG. 1.

20 is an explanatory diagram showing an example of a model system extraction screen displayed by the source code evaluation device in FIG.

21 is an explanatory diagram showing an example of a system evaluation data file change screen displayed by the source code evaluation device in FIG. 1. FIG.

22 is an explanatory diagram showing an example of a method for setting a reference value for system evaluation by the system evaluation data changing unit 32 in FIG.

FIG. 23 is an explanatory diagram showing an example of a display screen showing the relationship between the degree of danger of each program and the number of troubles, which is displayed by the trouble information display section 41 of FIG. 1;

24 is an explanatory diagram showing an example of a relationship display screen for displaying the relationship between the metrics value of each program and the number of troubles displayed by the trouble information display section 41 of FIG. 1. FIG.

25 is an explanatory diagram showing an example of a program evaluation data file change screen displayed by the program evaluation data change section 42 of FIG. 1. FIG.

[Explanation of symbols]

 1 ... Information transmission unit 2 ... Quality evaluation unit 3 ... System evaluation data file change unit 4 ... Program evaluation data file change unit 5 ... Database 6 ... Host 7 ... Terminal 11 ... Information collection unit 12 ... Information feedback unit 21 ... Quality Metric value measurement unit 22 ... System quality evaluation unit 23 ... Danger program extraction unit 31 ... Model system extraction unit 32 ... System evaluation data change unit 41 ... Trouble information display unit 42 ... Program evaluation data change unit 51 ... Program source code file 52 ... System evaluation data file 53 ... Trouble information file 54 ... Program evaluation data file 55 ... Evaluation result file

Claims (3)

[Claims] 1. A source code evaluation device for evaluating the source code of a software system developed in a distributed development environment consisting of a plurality of terminals, which is developed from each terminal in which a program constituting a system to be evaluated is developed. Information collecting means for collecting information on the source code of the program being executed and trouble that has occurred, quality metric value measuring means for measuring the value of the quality metric from the source code collected by the information collecting means, and the evaluation Based on the quality metric value obtained by the quality metric value measuring means with respect to the source code of the program constituting the target system, the system quality evaluating means for evaluating the quality of the evaluation target system, and the system quality evaluating means Trabe based on system evaluation results A dangerous program extracting means for extracting a dangerous program that is likely to be connected to, and an information feedback means for feeding back the system evaluation result obtained by the system quality evaluation means and the dangerous program extracting means and the risk degree of the program to the respective terminals. A source code evaluation device comprising: 2. A system evaluation data file that stores system evaluation data for performing quality evaluation of a system to be evaluated by the system quality evaluation means, and a system evaluation data file from the source code collected by the information collecting means. Model system extraction means for selecting a system to be a model, and a model system selected by the model system extraction means are analyzed to determine a quality metric suitable for system evaluation, and the quality metric data is used for the system evaluation. 2. The source code evaluation device according to claim 1, further comprising system evaluation data changing means for changing the system evaluation data in the data file. 3. The characteristics and troubles of the program based on the program evaluation data file storing the program evaluation data for extracting the dangerous program by the dangerous program extracting means and the trouble information collected by the information collecting means. Trouble information display means for displaying the relationship with the number of cases, based on the relationship displayed by the trouble information display means, to determine a quality metric suitable for dangerous program extraction, the program evaluation data by the quality metric data 2. The source code evaluation device according to claim 1, further comprising program evaluation data changing means for changing the program evaluation data in the file.