JP2006059276A - Source code evaluating system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a source code evaluating system capable of objectively evaluating a coding capability of a software engineer or a company to which the engineer belongs. <P>SOLUTION: The source code evaluating system 100 has: a source code management part 101 for managing information on an engineer unitarily who has coded a source code 103; a quality inspecting part 104 for inspecting the source code 103; a data storage part 111 for storing a variety of information necessary for inspection or the like; and a quality evaluating part 107 for analyzing the result of inspection and the stored data to output an evaluation report 110 which has evaluated a quality state of the source code 103 and the capability of the engineer. The quality evaluating part 107 performs inspection and evaluates the source code and the capability by the source code 103 unit, the engineer unit, the company unit, and the project 102 unit. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a source code evaluation system for evaluating an engineer's coding ability in software.

  In the development of computer software (hereinafter simply referred to as “software”), maintain and improve the coding ability of each engineer to a certain level or higher in order to carry out the development that engineers who develop multiple programs are engaged as planned. Therefore, it is necessary to evaluate the coding ability of each engineer at any time.

  Note that coding here refers to the work of translating and generating the contents of abstract design documents such as specifications and flowcharts into specific source code using a programming language.

  When grasping the coding ability of a software development engineer, there is a known method of referring to development history such as information processing test and vendor test qualifications, development work contents and years involved in the past. However, the presence or absence of qualifications does not directly indicate the ability and experience of engineers in coding practice, and just because they are qualified does not necessarily mean that source code can be created. Moreover, the development history can only grasp the ability of engineers before starting the development work.

  In the conventionally known technology, a technique is used in which inspection is performed during the development work period to grasp the ability of each engineer and to improve the ability. Here, inspection means that a reviewer or the like analyzes and examines whether there is a defect in the source code.

FIG. 29 is an explanatory diagram of a work flow of inspection conventionally performed.
In the software development project 102 designed for software development, engineers (such as programmers) 2901 who are engaged in software development (hereinafter simply referred to as “engineers”) 2901 are the contents of abstract design documents such as specifications and flowcharts. Coding based on the above, and creating a source code that will be a blueprint of software written using a programming language. The source code 103 is a group of instructions for causing a computer created by a programming language to execute, as shown in the schematic diagram of FIG.

  In addition, the project indicates the entire business for software development, and the content and scale of the software to be developed, the time required for development, etc. are not limited.

  As shown in FIG. 29, the reviewer 2902 performs inspection on the source code 103 to determine whether there is a bug and whether the reference rule is correct. This reviewer 2902 is a skilled engineer expert who is in charge of analyzing and analyzing programs created by engineers 2901 (usually the superior of each programmer), and inspection provides each source code for each programming language and project. It will be examined in accordance with the established standards and standards.

  The reviewer 2902 evaluates the inspection results and summarizes the evaluation results as an inspection result report.

FIG. 31 shows a schematic diagram as an example of the inspection result report 2904.
In the inspection result report 2904, the name of the reviewer 2902 is described in the “author” column 2904A, the report creation date is described in the “creation date” column 2904B, and the type of the source code 103 and the quantity of the source file are recorded in the “execution contents” column 2904C. Information that specifies the target and quantity of inspection.

  In the “Detection Item List” table 2904D, a “registration date” column 2904a for entering the inspection date and time, a “project name” column 2904b for entering the name of the project in which the coding was performed, and a source code 103 were created. “Engineer” column 2904c for filling in the name of engineer 2901, “Source name” column 2904d for filling in the source file name to be inspected, and inadequate detected from the generated source code 103 Corresponding items are entered in a “line number” column 2904e in which the line number where the location is present is entered and a “review point” column 2904f in which the grounds considered to be inappropriate are entered. In the “error tendency and analysis” column 2904E, the error tendency confirmed in the source code 103 is entered as a summary and evaluation of the inspection results.

  As shown in FIG. 29, the inspection result report 2904 as a result of the inspection by the reviewer 2902 is notified to the project manager 2205 responsible for the operation and management of the project in the software development project 102. Then, the project manager 2205 analyzes and examines the inspection result report 2904, and issues an instruction to correct the source code 103 to each engineer 2901 in order to remove the found defect.

  However, the above inspection result report 2904 must be prepared by the reviewer 2902 for each engineer 2901 who has the manual entry in the “List of items to be pointed out” table 2904D and the “Error trend and analysis” column 2904E. The burden on the reviewer 2902 is large.

  In particular, in a large-scale design and development project that involves multiple work processes where multiple engineers 2901 develop in a distributed development environment consisting of multiple terminals, many engineers 2901 receive a large amount of source code 103. As a result, the amount of the source code 103 exceeds the processing capability of the reviewer 2902, and it is often difficult to perform inspection continuously during the project.

  On the other hand, promoting the coding ability of engineers using source code is an important factor for ensuring quality in large-scale projects. The coding ability of current engineers is quantified numerically and presented as objective data. However, there is no system capable of presenting such information in the conventional system.

  In large-scale projects, coding is often outsourced to software companies, and there is a request from the project consignor to provide an index for objectively analyzing the coding ability of each company. At present, there is no mechanism, system, or specific system for quantitatively analyzing and judging the coding ability of a conventional software company.

  The present invention has been made in view of such circumstances, and an object thereof is to provide a source code evaluation system capable of objectively evaluating the coding ability of a software engineer or a company to which the engineer belongs.

  The object of the present invention is to provide a source code evaluation system for evaluating a source code generated for each work process in a design development project including a plurality of work processes developed in a distributed development environment including a plurality of terminals. A quality inspection unit that performs inspection for each generated source code, a result of the inspection that is output from the quality inspection unit, and centralized management of engineer information regarding the engineer who created the source code Management storage means, data storage means having rule information relating to the type of defect in the source code, and diagnosis history information relating to the result of the inspection performed by the quality inspection means on the source code in the past, and the diagnosis history information And the inspection result output by the quality inspection means. And quality evaluation means for evaluating the quality of the source code and the ability of the engineer to create the source code, the quality evaluation means for the inspection result information stored in the data storage means. Perform quality diagnosis for diagnosing the quality of the source code in the work process unit, the source code unit, and the developer unit, refer to the centralized management storage means for the diagnosis result, and totalize and output each unit Achieved by a source code evaluation system.

  According to the present invention, the quality inspection means automatically inspects the source code created by the engineer, inspects the source code created by the engineer for automatic inspection, and the quality evaluation means An evaluation report that can check the quality and quality transition can be automatically created, greatly reducing the workload of reviewers who check for similar errors over and over, and improving the efficiency of checking intermediate quality. I can plan.

  In addition, inspection and quality evaluation of a large amount of source code can be performed regularly and automatically, so introducing it to a large-scale project reduces the burden of reviewers on the inspection and evaluation of source code. Inspect large-scale projects easily and continuously for engineers.

  In addition, based on the results of ongoing inspections, it is possible to create an index to quantitatively analyze and judge the coding ability of the software engineer and the company to which the engineer belongs. The coding ability can be evaluated objectively.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings. In addition, the structure and step which attached | subjected the same code | symbol in drawing have shown the same structural requirement and the same step.

  FIG. 1 is a system configuration diagram showing code inspection using a source code evaluation system according to an embodiment of the present invention.

  The code inspection system 100A includes a development machine 121 used in a project (hereinafter simply referred to as “project”) 102 for developing software, a source code evaluation system 100 according to the present invention, and a management terminal 123. Prepare. The source code evaluation system 100 includes a source code management unit 101, a quality inspection unit 104, a quality evaluation unit 107, and a data storage unit 111. The quality inspection unit 104 includes a control unit 105 and a source inspection unit 106. The evaluation unit 107 includes a quality diagnosis unit 108 and a capability diagnosis unit 109.

  The development machine 121 is various computer terminals used by the engineer 2901 of the project 102 to develop the source code 103. The development machine 121 is connected to the source code evaluation system 100 via the intranet 122, and the management terminal 123 is managed by the project 102. These are various computer terminals used by the project manager 2205 for performing business operations, and are connected to the source code evaluation system 100 via a LAN or the like.

  In this code inspection system 100A, engineers 2901 describe the source code 103 using their development machines 121. At the development stage or after completion of development, the engineer 2901 accesses the source code management unit 101 of the source code evaluation system 100 through the intranet 122, and registers the developed source code 103 and information of the engineer 2901. Further, the project manager 2205 downloads the evaluation report 110 from the management terminal 123, examines the contents, and confirms the quality of the source code 103 in the project 102 and the coding ability of the engineer 2901.

FIG. 2 is a block diagram showing a configuration of a source code evaluation system according to an embodiment of the present invention.
The data storage unit 111 of the source code evaluation system 100 is an external storage device, and stores engineer information 112, coding progress information 113, diagnosis history information 114, rule information 115, and inspection result information 116. FIG. 3 will be described later together with a detailed flow.

FIG. 4 is a diagram showing a data structure of the engineer information 112.
The engineer information 112 is data relating to an engineer 2901 who is involved in coding.

  The employee number of the engineer 2901 shown in the “employee number” column 401, the name of the engineer 2901 shown in the “name” column 402, the company name to which the engineer 2901 belongs in the “company name” column 403, and , The source type as the programming language used to create the source code 103 shown in the “source type” column 404, the number of projects that the engineer 2901 shown in the “number of projects” column 405 has engaged in the past, It consists of data on evaluation transition and correction ability for the source code 103 created by the engineer 2901 shown in the “ability evaluation transition” column 406. Details of the ability evaluation displayed in the “ability evaluation transition” column 406 will be described later.

FIG. 5 is a diagram showing a specific example of the data structure in the coding progress information 113.
The coding progress information 113 is data for recording an outline of coding progress in the project 102.

  The name of the project 102 in which the source code 103 shown in the “project name” column 501 is created, the source name given to the source code 103 shown in the “source name” column 502, and the “update date / time” column 503 The date and time when the list of the latest source code 103 to be created was recorded in year, month, day, hour, minute and second, the source type of the source code 103 shown in the “source type” column 504, and the “number of steps” column 505 The number of steps included in the displayed source code 103, the employee number of the engineer 2901 who created the source code 103 shown in the "employee number" column 506, and the inspection of the source code 103 shown in the "inspection date" column 507 Is made up of the date of

FIG. 6 is a diagram showing a specific example of the data structure of the diagnosis history information 114. As shown in FIG.
The diagnosis history information 114 is a database of data related to the results of inspections performed on the source code 103 in the past.

  The name of the project 102 in which the source code 103 shown in the “project name” column 601 is created, the date of the inspection shown in the “diagnosis date” column 602, and the inspection shown in the “source name” column 603 are displayed. The source name of the performed source code 103 and a display in which the date and time when the list of the latest source code 103 shown in the “update date and time” column 604 is created are recorded in units of year, month, day, hour, minute and second. It should be noted that the diagnosis date displayed in the “diagnosis date” column 602 does not necessarily match the inspection date of the source code.

FIG. 7 is a configuration diagram showing a specific example of the data configuration of the rule information 115.
The rule information 115 indicates data on the type of coding defect to be confirmed in the inspection 106.

  The rule name, which is an identification symbol assigned to each type of defect shown in the “Rule Name” column 701, the importance level indicating the degree of influence that the failure shown in the “Importance” column 702 has on the system, and the “Rule Type” "", The rule type as the defect category shown in the "703" field, and the specific contents of the defect represented by the text shown in the "check content" field 704. The specific contents of this bug are items that are considered to be likely to be mistakes and mistakes when describing the source code 103 in the programming language. For example, the variables are initialized in the loop, etc. This includes deficiencies in the description, grammatical deficiencies such as an empty while statement, substitution in if conditional expressions, and the like.

FIG. 8 is a diagram showing the structure of a definition table indicating importance.
The definition of importance displayed in the “importance” column 702 is provided separately as a definition table. The definition table 801 includes an “importance” column 801a, a “need to be modified” column 801b, a “system influence” column 801c, and an “evaluation point” column 801d. A rule whose “importance” column 801a is “most important” needs to be corrected (displayed as “required” in the “need to be corrected” column 801b). A serious failure may occur ("Large" is displayed in the "System Impact" column 801c).

  A rule with “important” in the “importance” column 801a needs to be corrected, and if left unattended, a minor failure may occur in the system (“system impact”) column 801c “Small” is displayed. ) Indicates a defect. The rule of “Warning” in the “Importance” column 801a needs to be corrected individually and indicates a problem that may cause a serious failure in the system if left unattended. The rule of “notification” in the “importance” column 801a needs to be corrected individually and indicates a problem that may cause a minor failure in the system if left unattended.

FIG. 9 is a diagram showing the structure of a definition table showing the definition of rule types.
The definition of the rule type displayed in the “rule type” column 703 is also provided as a definition table.

  Representative description rules of the procedural programming language are listed in the “rule type” column 901a, and an error summary for this description rule is displayed in the “content” column 901b. A rule corresponding to a specific defect in coding is read into the rule information 115.

FIG. 10 is a diagram showing a specific example of the data structure of the inspection result information 116.
The inspection result information 116 indicates a data group in which defects extracted as a result of the inspection are recorded.

  The name of the project 102 in which the source code 103 shown in the “project name” column 1001 is created, the source name of the source code 103 that has been inspected shown in the “source name” column 1002, and the “update date” column 1003 The date and time when the list of the latest source code 103 shown was created, recorded in units of year, month, day, hour, minute and second, and the rule name that is the identification symbol assigned to each type of defect shown in the “Rule Name” column 1004 A line number in which a defect is detected in the source code 103 indicated in the “line number” column 1005, a message expressing the specific content of the defect indicated in the “message” column 1006, and an “inspection date” And the date when the inspection shown in the column 1007 is performed. The message shown in the “message” column 1006 corresponds to the display in the “rule type” column 901a in the definition table of FIG.

  Next, the quality evaluation criteria and display method of the source code 103 applied to the source code evaluation system 100 according to the present embodiment will be described.

FIG. 11 is an explanatory diagram showing quality evaluation criteria of the source code evaluation system 100 according to the present embodiment.
As shown in FIG. 8, the source code evaluation system 100 sets the evaluation points weighted depending on the items in the “importance” column 801a of the definition table 801 as displayed in the “evaluation points” column 801d. . For all sources in which defects were detected as a result of inspection, the source code is the sum of the values obtained by multiplying the value displayed in the “number of steps” column 505 by the value described in the “evaluation point” column 801d as a weighting function. The value divided by the scale of 103 kilosteps is called the evaluation point, and the lower the point, the higher the quality of the source code.

  In FIG. 11, as shown in the “evaluation points” column 1101c, evaluation points from 0 points to 30 points are provided. On the other hand, what these evaluation points are divided into appropriate values and displayed with easy-to-read symbols are called quality evaluation symbols.

In FIG. 11, the evaluation points are divided into a total of 6 areas every 5 points. As shown in the “quality evaluation symbol” column 1101b, 5 white stars for the 0-5 point areas and 4 white stars for the 6-10 point areas. .... 1 white star for the 21-25 point area and 1 black star for the 26-30 point area as the quality evaluation symbols. The more stars, the white star than the black star. Shows that the quality of the source code 103 is high. In the specific example of FIG. 11, as shown in the “ability evaluation” column 1101a, the evaluation points described in the “evaluation point” column 1101c are 0 to 10 points, and the ability evaluation level A is 11 to 20 points. Is set as a capability evaluation level C, with a capability evaluation level B of 21 to 30 points.
And the example of the capability evaluation transition based on this capability evaluation level is shown in FIG.

FIG. 12 is a schematic diagram of judgment criteria for ability evaluation transition and correction ability.
In FIG. 12, the ability is evaluated by the correlation between the evaluation axis (evaluation point) in the vertical axis direction and the time axis (time) in the horizontal axis direction.

  The vertical axis is the number of points added for each deduction target in the confirmation items related to the quality of the source code 103, and the ability evaluation level A (0 points or more and less than 10 points), ability evaluation level B (10 points or more and 20 points) Less than) and ability evaluation level C (20 points or more and less than 30 points).

  In FIG. 12, the evaluation of the source code 103 is that A is the highest and C is the lowest. On the other hand, the horizontal axis is a parameter for the number of days required to create the source code 103, and is divided into three periods: a period a which is a source creation start period, a period b which is a creation intermediate period, and a period c which is a creation end period. . The + correction capability symbol 1202a and the −correction capability symbol 1202b indicate the correction capability (hereinafter simply referred to as “correction capability”) as the capability of the engineer 2901 to correct the defect in the source code 103. .

  The + corrected ability symbol 1202a indicates that the source code 103 of the initial ability evaluation level B or C is corrected in a short period of time and the defect is corrected to the ability evaluation level A, and the -corrected ability symbol 1202b is the initial ability evaluation level. It shows a state where it takes a long time until the defect of the source code 103 which is B or C is corrected and reaches the ability evaluation level A, or the ability evaluation level does not reach A until the end.

  Diagnosis of ability evaluation transition is performed according to the following procedure. First, when the quality evaluation does not change between the start time and the end time, the ability evaluation symbol is displayed as it is. For example, an engineer 2901 whose evaluation is A at the start of the project 102 and whose evaluation at the end is A is diagnosed as ability evaluation transition A. When the quality evaluation changes between the start time and the end time, the evaluation at the start time and the evaluation at the end time are displayed side by side. For example, an engineer 2901 whose evaluation is B at the start of the project 102 and whose evaluation at the end is A diagnoses the ability evaluation transition BA.

  Next, when the quality evaluation changes between the start time and the end time, the period of time until the next ability evaluation standard is measured.

  In the present embodiment, for the sake of simplicity of explanation, if the average period of transition to the ability evaluation standard A is within 14 days, the + corrected ability symbol 1202a takes 14 days or more or does not become A until the end. In such a case, the -correction ability symbol 1202b is added to the end of the symbol. In the present embodiment, for the sake of simplicity, inspection is performed at the elapse of 14 days and 28 days after the creation of the source code 103 is started, and the evaluation in the previous inspection and the evaluation in the subsequent inspection are performed. By contrast, ability evaluation transition and correction ability shall be judged.

  FIG. 12 is a schematic diagram of judgment criteria for ability evaluation transition and correction ability created based on the above-mentioned criteria. An example of criteria for judging technical ability evaluation transition and correction ability created based on the above-mentioned criteria is shown.

  Since the first evaluation example 1201a has reached the technical skill evaluation level A when 14 days have passed since the start of coding, only “A” is evaluated, and neither the + correction ability symbol 1202a nor the −correction ability symbol 1202b is displayed.

  In the second evaluation example 1201b and the third evaluation example 1201c, since the technical evaluation level B was 14 days after the start of coding and reached the technical evaluation level A after 28 days, the technical evaluation transition “BA ”And a + correction ability symbol 1202a is displayed.

  The third evaluation example 1201c is evaluated as the technical ability evaluation transition “CA” because the technical ability evaluation level C has reached the technical ability evaluation level A when 28 days have elapsed since 14 days have elapsed since the start of coding. A + correction ability symbol 1202a is displayed.

  In the fourth evaluation example 1201d, although the evaluation point is improved after 28 days than after 14 days from the start of coding, the technical ability evaluation level A is not reached when 28 days have passed. "CB" is evaluated, and the -correction ability symbol 1202b is displayed.

  In the fifth evaluation example 1201e, the technical skill evaluation level B remains at both 14th and 28th days after the start of coding, and the technical skill evaluation transition “BB” is evaluated. Is displayed.

  The notation shown in the “technical skill evaluation transition” column 406 of FIG. 4 displays the technical skill evaluation transition of coding and the correction ability of the source code 103 shown in the above example.

  In addition, the frequency | count and interval of an inspection in this Embodiment are illustrations, Depending on the aspect, inspection may be performed more than twice, and the interval of inspection may be longer or shorter than 14 days. Good.

  FIG. 3 is a data configuration diagram showing a connection configuration of the source code evaluation system 100 shown in FIG.

  Hereinafter, the operation of each unit of the source code evaluation system 100 according to the present embodiment will be described with reference to this drawing.

  The source code management unit 101 reads the source code 103. At this time, information on the project included in the source code 103 and information such as the name of the engineer 2901 are also read and registered in the source code management unit 101, and engineer information 112 of the engineer 2901 who created the source code 103 is registered. Is read into the source code management unit 101. The registered information is stored in the engineer information 112 and the coding progress information 113.

  Since the source code management unit 101 manages the source code 103 in units of a plurality of projects 102, even if the engineer 2901 is developing across several projects 102, the source code 103 as an inspection target is used. Can be obtained. The source code 103 has the form shown in the schematic diagram of FIG.

  The source code management unit 101 outputs a correspondence between the engineer 2901 and the source code name for the coding progress information 113.

  The control unit 105 periodically checks the information for each project 102 stored as the coding progress information 113, and creates a list of newly registered source codes 103. Then, the control unit 105 reads the coding progress information 113 and acquires the source code 103. The source code 103 acquired by the control unit 105 is sent to the source inspection unit 106, and the source inspection unit 106 inspects the received source code 103. The control unit 105 outputs diagnosis history information 114 for the diagnosed source code 103. The source inspection unit 106 reads the rule information 115 designated for each project 102, inspects the source code 103, and outputs the result. The inspection result is registered and accumulated in the inspection result information 116.

  The inspection result information 116 is read into the quality diagnosis unit 108, and the quality diagnosis unit 108 considers each defect in the read inspection result information 116 based on the definition table 801 shown in FIG. 8 and the influence on the system. The importance is determined, and the evaluation point defined in the “evaluation point” column 801d based on the definition of the “importance” column 801a is used as an evaluation point variable. The quality diagnosis unit 108 calculates a value obtained by dividing the evaluation point variable by the scale (number of steps) of the source code 103 as an evaluation point. The quality diagnosis unit 108 aggregates the evaluation points for each rule, source code 103, and engineer 2901 shown in FIG.

  The quality diagnosis unit 108 also outputs the inspection result information 116 to the capability diagnosis unit 109. At the end of the project 102, the capability diagnosis unit 109 sets the source code 103 created by each engineer 2901 in each project 102 to a desired quality. Analyze the transition of past evaluation on how long it took to converge, etc. for each engineer 2901, calculate the evaluation transition of coding ability and the correction ability of the source code 103, and obtain the engineer information 112 Update and repeat the process from the beginning. The above-mentioned various information stored in the engineer information 112 is converted into data, so that each engineer 2901 can write the source code 103 with a desired quality when the next project 102 is performed, and the desired information It can be used as an index for determining how long it takes to write the quality source code 103.

  The source code evaluation system 100 outputs the evaluation report 110 as electronic information and displays it on the display of the management terminal 123.

  Hereinafter, an example of the evaluation report 110 output from the source code evaluation system 100 according to the embodiment of the present invention will be described with reference to FIG.

FIG. 13 is a diagram showing a form layout of the quality evaluation report 1301 related to the project 102.
The quality evaluation report 1301 includes a title display unit 1302, a diagnosis date display unit 1303 that displays the date on which the source code 103 was diagnosed by inspection, and a project name display unit 1304 that displays the name of the project 102 in which the source code 103 was created. A project information display area 1305, a transition graph 1306 of evaluation points, and a diagnosis result display area 1307 for displaying an outline of the diagnosis result in units of rules.

  The project information display area 1305 is provided with a quality evaluation and evaluation value display unit 1305a for displaying the quality evaluation and evaluation value of the project 102 subject to inspection and evaluation based on the criteria shown in FIG. The number of sources in the project 102 to be evaluated, the size of the source code 103 displayed in kilosteps, the number of engineers 2901, the total number of detected defects in the evaluation results, and detection of defects for each importance level The number of cases is displayed.

  In the diagnosis result display area 1307, the rule name in the "rule name" column 1307a, the importance defined in the definition table 801 in the "importance" column 1307b, and the "rule type" in the definition table 901 in the "rule type" column 1307c The rule type defined in the column 901a, the content of the rule defined in the “content” column 901b of the definition table 901 detected as a defect in the “detected content” column 1307d, and the defect detected in the “detected number” column 1307e Aggregation result, “Number of sources” column 1307f displays the aggregation result of the number of source codes detected as a defect, and “Number of people” column 1307g displays the aggregation result of engineer 2901 detected as having created a defect for each rule. Is done.

FIG. 14 is an explanatory diagram showing a form layout example of the quality evaluation report 1401 regarding the source code.
The quality evaluation report 1401 includes a title display unit 1402, a diagnosis date display unit 1303, a project name display unit 1304, a project information display region 1305, an evaluation graph 1403, and a diagnosis result display region that displays an overview of the diagnosis result in source units. It consists of 1404.

  In the diagnosis result display area 1404, the “source name” column 1404a is defined as the source name, the “update date” column 1404b is the updated date, the “name” column 1404c is the name of the engineer 2901, and the “evaluation” column 1404d is defined in FIG. , The evaluation point defined in FIG. 11 in the “Evaluation P” column 1404e, the source size in the “Scale” column 1404f, and the rule in the “Rule” columns 1404g, 1404g,. In the “total” column 1404h, the total number of detected defects, and in the “required” column 1404i, defects that must be corrected (the definition “displayed in the“ importance ”column 702 in FIG. The sum of the number of detections of “most important” and “failures corresponding to“ important ””, the “individual” column 1404j, the failure to be corrected individually (the “warning” in the definition displayed in the “importance” column 702 of FIG. 7 and The sum of the number of detections of “failure corresponding to“ notification ”” is displayed.

  In the evaluation graph 1403, “evaluation P” and the top 10 sources among the sources with high evaluation points in the description column 1404e are displayed as “evaluation worst 10” as a bar graph. The unit of the graph is the same evaluation point as the “Evaluation P” entry column 1404e.

  FIG. 15 is an explanatory diagram showing a form layout example of the quality evaluation report 1501 regarding the engineer 2901 displayed on the display of the management terminal 123.

  The quality evaluation report 1501 includes a title display unit 1502, a diagnosis date display unit 1303, a project name display unit 1304, a project information display region 1305, an evaluation graph 1503 showing evaluations of the top 10 engineers 2901 with bad evaluations, and diagnosis results Are displayed in a diagnosis result display area 1504 for displaying an outline of the engineer in units of 2901 engineers.

The following contents are displayed in the diagnosis result display area 1504, respectively.
The “engineer” column 1504a has the name of the engineer 2901, the “company name” column 1504b has the company name to which the engineer 2901 belongs, the “evaluation” column 1504c has the quality evaluation symbol defined in FIG. ”Column 1504d is the evaluation point defined in FIG. 11,“ Scale ”column 1504e is the source size,“ Rule ”columns 1504f, 1504f,. Is displayed.

  The total number of detected defects is displayed in 1504g, and the number of detected defects corresponding to “most important” and “important” in the definition displayed in the “importance” column 702 of FIG. 7 is displayed in the “required” column 1504h. The sum of is displayed.

  In the “individual” column 1504i, the sum of the detected numbers of defects corresponding to “warning” and “notification” in the definition displayed in the “importance” column 702 of FIG. 7 is displayed, and the “last evaluation transition” column 1504j. Is displayed with the ability evaluation transition and the correction ability in the previous project 102, respectively.

  In the evaluation graph 1503, the evaluations of the top 10 engineers 2901 having high evaluation points in the “Evaluation P” entry field 1504d are displayed as “Evaluation worst 10” in a bar graph.

  FIG. 16 is an explanatory diagram showing a form layout example of a quality evaluation report 1601 related to a company displayed on the display of the management terminal 123.

  The quality evaluation report 1601 includes a title display unit 1602, a diagnosis date display unit 1303, a project name display unit 1304, a project information display region 1305, a graph 1603 indicating the top 10 companies with poor evaluations, and an overview of the diagnosis results. It consists of a diagnosis result display area 1604 that is displayed for each company to which it belongs.

The “company name” column 1604a includes the company names to which the engineers 2901 belong, the “evaluation” column 1604b includes the quality evaluation symbols defined in FIG. 11, the “evaluation P” column 1604c includes the evaluation points defined in FIG.
The “scale” column 1604c displays the source size, and the “rule” columns 1604e, 1604e,... Each display the number of defects detected for each rule.

Furthermore, the “total” column 1604f displays the total number of defects detected, and the “required” column 1604g displays the defects corresponding to “most important” and “important” in the definition displayed in the “importance” column 702 of FIG. The sum of the number of detections,
In the “Individual” column 1604h, the sum of the number of detected defects corresponding to “Warning” and “Notification” in the definition displayed in the “Importance” column 702 of FIG. The ability evaluation transition and the correction ability in the project 102 are respectively displayed.

  In the graph 1603, the evaluations of the top 10 companies among the companies with the high evaluation points in the “Evaluation P” entry field 1604c are displayed as “Evaluation worst 10” in a bar graph.

  In the present embodiment, in addition to the quality of the source code 103, it is also possible to evaluate the coding ability of the engineer 2901 who develops the source code 103 and the company to which the engineer 2901 belongs.

FIG. 17 is an explanatory diagram showing a form layout example of the technical evaluation report 1701.
The layout of the technical evaluation report 1701 related to the engineer 2901 displayed on the display of the management terminal 123 includes the following items.

  The ability evaluation report 1701 includes a title display section 1702, a diagnosis date display section 1303, an engineer name and company name display section 1703, an engineer information display area 1704, an ability evaluation transition display area 1705, and a transition indicating evaluation point transition. It is composed of a graph 1706 and a diagnostic result display area 1707 for each rule.

  The engineer information display area 1704 displays the same items as the project information display area 1305, and the ability evaluation transition display area 1705 displays the ability evaluation transition and correction ability in the previous project 102, which are defined in FIG. Of the rule types, the top 3 items with the highest number of detected defects are output as “areas requiring attention”.

In the transition graph 1706, the vertical axis represents the evaluation point, and the horizontal axis represents the date on which the inspection was performed.
The transition of evaluation points for each day of the engineer 2901 displayed in the engineer name and company name display unit 1703 is displayed in a line graph.

  In the diagnosis result display area 1707, the “rule name” column 1707a has the rule name, the “importance” column 1707b has the importance defined in FIG. 8, the “type” column 1707c has the rule type defined in FIG. The contents of the rule defined in FIG. 9 are displayed in the “check content” column 1707d, the total number of detected defects in the “detected number” column 1707e, and the source code detected as a defect in the “number of sources” column 1707f. Each number is displayed.

FIG. 18 is an explanatory diagram showing a form layout example of the capability evaluation report 1801.
The layout of the company capability evaluation report 1801 displayed on the display of the management terminal 123 is composed of the following items.

  Title display section 1802, diagnosis date display section 1303, company name display section 1803, company information display area 1804, evaluation point transition graph 1805, and diagnosis result display that displays an overview of diagnosis results in units of engineers 2901 An area 1806 is included.

  In the transition graph 1805, the vertical axis represents an evaluation point and the horizontal axis represents an inspection date.

  Changes in the evaluation points of the company displayed in the company name display area 1803 are displayed as a line graph.

  The name of the engineer 2901 who created the source code in the “engineer name” column 1806a, the importance defined in FIG. 8 in the “importance” column 1806b, and the definition defined in FIG. 11 in the “evaluation P” column 1806d Evaluation point, “Scale” column 1806e is the source size, “Rules” column 1806e, 1806e,... Is the number of defects detected for each rule, and “Total” column 1806f is the number of defects detected. Total, “required” column 1806g shows the sum of the number of detected defects corresponding to “most important” and “important” in the definition displayed in “importance” column 702 of FIG. 7, and “individual” column 1806h shows 7 is the sum of the number of detected defects corresponding to “Warning” and “Notification” in the definition displayed in the “Importance” column 702, and the “Last evaluation change” column 1806i shows the capability evaluation change in the previous project 102 and Each correction ability is displayed.

  FIG. 19 is an explanatory diagram showing a form layout example of the quality transition report 1901 related to the project 102.

  The quality transition evaluation report 1901 related to the project 102 displayed on the display of the management terminal 123 includes a title display unit 1902, a project name display unit 1903, and a project quality transition result display area 1904.

  “Date” column 1904a is the date of inspection, “Evaluation” column 1904b is the quality evaluation symbol defined in FIG. 11, “Evaluation P” column 1904c is the evaluation point defined in FIG. 11, and “Scale” column 1904d is the source size, “rule” columns 1904e, 1904e,... Are the number of detected defects for each rule, “total” column 1904f is the total number of detected defects, and “required” column 1904g is FIG. 7 is displayed in the “importance” column 702 of FIG. 7 in the sum of the number of detected defects corresponding to “most important” and “important” in the definition displayed in the “importance” column 702 The sum of the detected number of defects corresponding to “Warning” and “Notification” in the definition, and the “Transition” field 1904i display the detected number of defects displayed in the “Individual” field 1904h in black squares in units of 50. In addition, the number of detected defects displayed in the “Required” column 1904g is displayed in white squares in units of 50. Graph represents the approximate number is displayed respectively.

  FIG. 20 is an explanatory diagram showing a form layout example of the quality transition report 2001 related to the source. A quality transition report 2001 displayed on the display of the management terminal 123 includes a title display unit 2002, a source name display unit 2003, and a source quality transition result display region 2004.

  “Date” column 2004a, “Evaluation” column 2004b, “Evaluation P” column 2004c, “Scale” column 2004d, “Rules” column 2004e, 2004e,..., “Total” column 2004f, The display contents of the “required” column 2004g, the “individual” column 2004h, and the “transition” column 2004i are the same as the display contents of the quality transition result display area 1904 in the evaluation report 1901 related to the project shown in FIG.

FIG. 21 is an explanatory diagram showing a form layout example of the quality transition report 2101 regarding the engineer 2901.
The quality transition report 2101 displayed on the display of the management terminal 123 includes a title display unit 2102, a technician name / company name display unit 2103, and a quality transition result display region 2104 of the technician 2901.

  “Date” field 2104a, “Evaluation” field 2104b, “Evaluation P” field 2104c, “Scale” field 2104d, “Rule” fields 2104e, 2104e,..., “Total” field 2104f, The display contents of the “essential” column 2104g, the “individual” column 2104h, and the “transition” column 2104i are the same as the display contents of the quality transition result display area 1904 in the evaluation report 1901 related to the project shown in FIG.

FIG. 22 is an explanatory diagram showing a form layout example of the quality transition report 2201 related to the engineer 2901.
The quality transition report 2201 displayed on the display of the management terminal 123 is composed of a title display section 2202, a company name display section 2203, and a company quality transition result display area 2204.

  The “date” field 2204a, “evaluation” field 2204b, “evaluation P” field 2204c, “scale” field 2204d, “rule” fields 2204e, 2204e,..., “Total” field in the quality transition result display area 2204 The display contents of 2204f, “required” field 2204g, “individual” field 2204h, and “transition” field 2204i are the same as the display contents of the quality transition result display area 1904 in the evaluation report 1901 related to the project shown in FIG.

  FIG. 23 is a flowchart showing the flow of processing of the source management function in the source code management unit of the source code evaluation system.

  Hereinafter, the processing operation for source management of the source code management unit 101 will be described based on this flowchart.

  The source code management unit 101 displays a screen prompting the accessing engineer 2901 to input the name and employee number of the project 102 on the display of the development machine 121 (step 2301). The data of the name of the project 102 input by the engineer 2901 is acquired (step 2302), and the employee number data is acquired (step 2303).

  When the name and employee number of the project 102 are acquired, the source code management unit 101 displays a screen prompting the engineer 2901 to input the latest source code 103 created by the engineer 2901 on the display of the development machine 121. The latest source code 103 is acquired (step 2304).

  Next, the source code management unit 101 checks the file name and the last update date / time of the acquired source code 103 (step 2305). The source code management unit 101 determines the type of the source code from the extension of the file name of the source code (step 2306).

  The source code management unit 101 measures the number of lines in the source code (step 2307). The source code management unit 101 includes a “project name” column 501, a “source name” column 502, a “file update date / time” column 503, a “source type” column 504, “number of steps” in the coding progress information 113 of the data storage unit 111. The obtained source code 103 is inserted and registered in the “column” 505 and the “employee number” column 506 (step 2308).

  FIG. 24 is a flowchart showing a process flow of the instruction processing function in the control unit 105 of the source code evaluation system 100.

  Hereinafter, the operation of the instruction processing of the control unit 105 will be described based on this flowchart.

  The control unit 105 periodically starts when the inspection execution time comes (step 2401), and backs up the execution environment in case an error occurs during execution (step 2402).

  The control unit 105 reads a compilation environment such as a library or a module necessary for compiling the source code 103 (step 2403).

  The control unit 105 selects and sets a rule module suitable for the state of the project 102 as a rule for examination in the inspection (step 2404). The control unit 105 searches the coding progress information 113 and creates a list of the latest source code 103 for the accumulated source code 103 (step 2405).

  The control unit 105 checks the current date, and in the diagnosis history information 114, as the source code data to be inspected, the project name in the “project name” column 601, the diagnosis date in the “diagnosis date” column 602, and the “source name” column 603 The last update date and time of the source file displayed in the “update date and time” column 604 is inserted (step 2406). Next, the control unit 105 reads the latest source code 103 (step 2407) and compiles (step 2408).

  The control unit 105 selects a file that has been updated since the previous diagnosis from the list of the latest source code 103 (step 2409). The control unit 105 performs filtering in order to mark a portion that is not subject to inspection in the file that has been updated since the previous diagnosis (step 2410).

  The control unit 105 calls the source inspection unit 106 and executes inspection (step 2411). The control unit 105 calls the quality diagnosis unit 108, totals the inspection results, and gives an evaluation (step 2412).

  The control unit 105 calls the capability diagnosis unit 109, analyzes the coding capability evaluation transition and the correction capability of the source code 103, and outputs an evaluation report 110.

  FIG. 25 is a flowchart showing the flow of processing of the inspection function in the source inspection unit 106 of the source code evaluation system 100.

  Hereinafter, the operation of the source inspection unit 106 will be described based on this flowchart.

  The source inspection unit 106 reads a rule module set as an inspection rule (step 2501). The source inspection unit 106 determines the number of source codes 103 to be analyzed at one time based on the machine specifications of the hardware that constitutes the source code evaluation system 100 (step 2502).

  The source inspection unit 106 collects the source code 103 to be analyzed into a set of several source codes 103 (step 2503). The source checking unit 106 executes step 2505 to step 2518 one by one for all sets of source codes 103 (step 2504) until it is executed for all sets of source codes 103 (step 2519).

  The source checking unit 106 executes step 2506 to step 2517 one by one for all the source codes 103 (step 2505) until it is executed for all the source codes 103 (step 2518).

  The source inspection unit 106 reads the source code 103 and inserts the current date into the “inspection date” column 507 of the corresponding source code 103 of the coding progress information 113 (step 2506). The source checking unit 106 generates a syntax tree from the read source code 103 (step 2507). The source checking unit 106 analyzes the contents of the file and generates file information corresponding to the syntax tree (step 2508). The source inspection unit 106 reads the native code called in the corresponding source code 103 (step 2509).

  Next, the source inspection unit 106 analyzes the native code and generates basic information about variables and functions. If the native code cannot be read, reflection is used to generate equivalent information (step 2510). The source inspection unit 106 executes steps 2512 to 2516 one by one for each registered rule (step 2511) until it is executed for all rules (step 2517). The source checking unit 106 runs a program that follows the syntax tree, and executes steps 2513 to 2515 one by one for each token in the syntax tree (step 2512) until all tokens are traced (step 2516).

  The source inspection unit 106 executes the read rule module, and determines whether it is caught by the inspection confirmation content (step 2513).

  When the result of the well inspection is positive, the source inspection unit 106 determines whether or not the line number in which the code is described is filtered out of the inspection target (step 2514). Next, when the determination result is negative, the source inspection unit 106 outputs the check result (step 2515) to the inspection result information 116 of the data storage unit 111 and accumulates it.

  FIG. 26 is a flowchart showing the flow of analysis processing and quality evaluation processing of the data analysis function in the quality diagnosis unit 108 of the source code evaluation system 100 in this embodiment.

  Hereinafter, data analysis processing and quality evaluation processing of the quality management unit 108 will be described based on this flowchart.

  The quality management unit 108 reads the diagnosis history information 114 of the project 102 (step 2601). The quality management unit 108 reads the project name displayed in the “project name” column 601 and the source name displayed in the “source name” column 603. All the inspection result information 116 of the source corresponding to the update date displayed in the “update date” column 604 is read (step 2602). The quality management unit 108 reads corresponding source data from the coding progress information 113 (step 2603).

The data of the corresponding engineer 2901 is read from the engineer information 112 (step 2604).
The quality management unit 108 reads the rule information 115 (2605). The quality management unit 108 executes step 2609 to step 2608 one by one for each diagnosis result (step 2606) until all dates are traced (step 2619).

  The quality management unit 108 acquires a source list that matches the diagnosis date (step 2607). The quality management unit 108 acquires the inspection result information 116 corresponding to the source list, and generates a collection that combines the above data into one record (step 2608).

  The quality control unit 108 totals the collection for the entire project 102 (step 2609). The quality management unit 108 aggregates the collection for each rule (step 2610). The quality management unit 108 aggregates the collection for each source (step 2611). The quality management unit 108 totals the collection for each engineer 2901 (step 2612). The quality management unit 108 aggregates the collection for each company (step 2613).

  The quality management unit 108 determines whether the update date is the latest (step 2614). If the result of step 2614 is positive, the quality management unit 108 selects 10 sources with the worst evaluation (step 2615).

  The quality management unit 108 selects 10 engineers 2901 having the worst evaluation (step 2616), and the quality management unit 108 selects 10 companies having the worst evaluation (step 2617). If the determination result in step 2605 is negative, the quality management unit 108 does not perform any special processing. It should be noted that the number of items to be selected at the time of selecting each of the poor evaluations at step 2615, step 2616, and step 2617 can be arbitrarily set.

  The quality management unit 108 outputs a quality evaluation report 1301 related to the project 102 (step 2619), and the quality management unit 108 outputs a quality evaluation report 1401 related to the source (step 2620).

  The quality management unit 108 outputs a quality evaluation report 1501 related to the engineer 2901 (step 2621), and the quality management unit 108 outputs a quality evaluation report 1601 related to the company (step 2622).

  The quality management unit 108 outputs a capability evaluation report 1701 related to the engineer 2901 (step 2623). Then, the quality management unit 108 outputs a capability evaluation report 1801 about the company (step 2624).

  The quality management unit 108 outputs a quality transition report 1901 related to the project 102 (step 2625). The quality management unit 108 outputs a quality transition report 2001 related to the source (step 2626). The quality management unit 108 outputs a quality transition report 2101 regarding the engineer 2901 (step 2627). The quality management unit 108 outputs a quality transition report 2201 regarding the company (step 2628).

FIG. 27 is a flowchart showing a flow of a totaling process of the data totaling function in the quality diagnosis unit 108 of the source code evaluation system 100 according to the present embodiment.
Hereinafter, details of the data totaling process of the quality diagnosis unit 108 will be described with reference to a flowchart.

  The quality diagnosis unit 108 acquires the number of data records of the inspection result information 116 included in the collection (step 2701). The quality diagnosis unit 108 prepares essential variables, individual variables, and variables for each rule, and initializes the values to 0 (step 2702). The essential variable is a function that fluctuates the item defined as “required” that needs to be corrected in the “necessary correction” column 801b shown in FIG. 8, and the individual variable is the “necessary correction” column 801b shown in FIG. This is a function that fluctuates items defined as “individual” in FIG. Next, the quality diagnosis unit 108 prepares an evaluation point variable for storing the evaluation point, and initializes the value to 0 (step 2703). Next, the quality diagnosis unit 108 prepares a step number variable for storing the number of steps, and initializes the value to 0 (step 2704). The quality diagnosis unit 108 executes processing from step 2706 to step 2711 one by one for all data included in the collection (step 2705) until it is executed for all data (step 2712).

  The quality diagnosis unit 108 increments the variable corresponding to the rule by 1 (step 2706). The quality diagnosis unit 108 retrieves the importance of the rule from the rule ID of the inspection result information 116 (step 2707). The quality diagnosis unit 108 determines whether the importance of the rule is the most important or important (step 2708).

  If the determination result in step 2708 is positive, the quality diagnosis unit 108 increments the essential variable by 1 (step 2709). If the determination result in step 2708 is negative, the quality diagnosis unit 108 increments the individual variable by 1 (step 2710).

  The quality diagnosis unit 108 adds the evaluation point corresponding to the importance of the rule to the evaluation point variable (step 2711). The quality diagnosis unit 108 assigns the number of engineers 2901 included in the collection to the engineer variable (step 2713). The quality diagnosis unit 108 substitutes the number of companies included in the collection into a company variable (step 2714). The quality diagnosis unit 108 executes the process of step 2716 one by one for all sources included in the collection (step 2715) until it is executed for all sources (step 2717).

  The quality diagnosis unit 108 adds the size of the source to the step number variable (step 2716). The quality diagnosis unit 108 substitutes the number of sources into the source variable (step 2718). The quality diagnosis unit 108 divides the evaluation point variable by the step number variable, and substitutes the obtained value for the evaluation point variable (step 2719).

FIG. 28 is a flowchart showing a processing flow of the capability evaluation function in the capability evaluation unit 109 of the source code evaluation system 100 according to the present embodiment.
Hereinafter, the capability evaluation process of the capability evaluation unit 109 will be described based on this flowchart.

  The ability evaluation unit 109 performs the subsequent processing only at the end of the project 102. The capability evaluation unit 109 acquires quality evaluation points of the first engineer 2901 during the period of the project 102, and calculates a corresponding capability evaluation (step 2801).

  The capability evaluation unit 109 acquires the quality evaluation point of the last engineer 2901 during the development period of the project 102, and calculates the corresponding capability evaluation (step 2802). The ability evaluation unit 109 determines whether the first and last ability evaluations match (step 2803). If the determination result in step 2803 is positive, the ability evaluation unit 109 sets the first ability evaluation as the final ability evaluation (step 2804), and displays the employee number and “source type” displayed in the “employee number” column 401 of the engineer information 112. The source type displayed in the “404” field, the capability evaluation transition and the correction capability displayed in the “ability evaluation transition” column 406 are updated, and the number of projects is incremented by 1 (step 2812).

  On the other hand, if the determination result in step 2803 is negative, the ability evaluation unit 109 arranges the first and last ability evaluation symbols and displays the -corrected ability symbol 1202b (step 2805).

  The ability evaluation unit 109 first checks the diagnosis date when the evaluation point of the engineer 2901 has changed during the period of the project 102 (step 2806). The capability evaluation unit 109 checks the diagnosis date when the capability evaluation of the engineer 2901 has changed to A during the period of the project 102 (step 2807). The ability evaluation unit 109 checks the fluctuation period by subtracting the diagnosis date of step 2806 from the diagnosis date of step 2807 (step 2808).

  The ability evaluation unit 109 determines whether the variation period is within 14 days (step 2809). If the determination result in step 2810 is positive, the ability evaluation unit 109 displays a + corrected ability symbol 1202a after the ability evaluation symbol. On the other hand, if the determination result in step 2810 is negative, the ability evaluation unit 109 displays a -corrected ability symbol 1202b after the ability evaluation symbol. Then, the ability evaluation unit 109 executes Step 2812.

It is a system configuration figure of a code inspection system using a source code evaluation system in one embodiment of the present invention. It is a block diagram which shows the structure of a source code evaluation system same as the above. It is a flowchart which shows the processing flow of a source code evaluation system same as the above. It is explanatory drawing which shows the data structure of the engineer information of a source code evaluation system same as the above. It is explanatory drawing which shows the data structure of the coding progress information of a source code evaluation system same as the above. It is explanatory drawing which shows the data structure of the diagnostic history of a source code evaluation system same as the above. It is explanatory drawing which shows the data structure of the rule information of a source code evaluation system same as the above. It is explanatory drawing which shows the importance of the rule in a source code evaluation system same as the above. It is explanatory drawing which shows the kind of rule in a source code evaluation system same as the above. It is explanatory drawing which shows the data structure of the inspection result information of a source code evaluation system same as the above. It is explanatory drawing which shows the quality evaluation criteria of a source code evaluation system same as the above. It is explanatory drawing which shows the example of a display of the capability evaluation transition and correction capability of a source code evaluation system same as the above. It is explanatory drawing which shows the form layout example of the quality evaluation report regarding the project of a source code evaluation system same as the above. It is explanatory drawing which shows the form layout example of the quality evaluation report regarding the source of a source code evaluation system same as the above. It is explanatory drawing which shows the form layout example of the quality evaluation report regarding the company of a source code evaluation system same as the above. It is explanatory drawing which shows the form layout example of the quality evaluation report regarding the company of a source code evaluation system same as the above. It is explanatory drawing which shows the form layout example of the technical evaluation report regarding the engineer of a source code evaluation system same as the above. It is explanatory drawing which shows the form layout example of the capability evaluation report regarding the company of a source code evaluation system same as the above. It is explanatory drawing which shows the form layout example of the quality transition report regarding the project of a source code evaluation system same as the above. It is explanatory drawing which shows the form layout example of the quality transition report regarding the source of a source code evaluation system same as the above. It is explanatory drawing which shows the form layout example of the quality transition report regarding the engineer of a source code evaluation system same as the above. It is explanatory drawing which shows the form layout example of the quality transition report regarding the company of a source code evaluation system same as the above. It is a flowchart which shows the flow of a process of the source management function in the source code management part of a source code evaluation system same as the above. It is a flowchart which shows the flow of a process of the instruction processing function in the control part of a source code evaluation system same as the above. It is a flowchart which shows the flow of a process of the inspection function in the source test | inspection part of a source code evaluation system same as the above. It is a flowchart which shows the flow of a process of the quality diagnostic function in the quality diagnostic part of a source code evaluation system same as the above. It is a flowchart figure which shows the flow of a process of the data totaling function in the quality diagnostic part of a source code evaluation system same as the above. It is a flowchart which shows the flow of a process of the capability diagnosis function in the capability diagnosis part of a source code evaluation system same as the above. It is explanatory drawing explaining the work flow in the conventional inspection. It is a schematic diagram of the source code to be evaluated in the conventional inspection. It is a schematic diagram which shows the example of the result of the conventional inspection.

Explanation of symbols

100 ... Source code evaluation system 101 ... Source code management part 102 ... Project 103 ... Source code 104 ... Quality inspection part 105 ... Control part 106 ... Source inspection part 107 ... Quality evaluation unit, 108 ... Quality assessment unit, 109 ... Ability diagnosis unit, 110 ... Evaluation report, 111 ... Data storage unit, 112 ... Engineer information, 113 ... Coding progress information, 114 ... Diagnosis information , 115 ・ ・ Rule information, 116 ・ ・ Inspection result information, 121 ・ ・ Development machine, 122 ・ ・ Intranet, 123 ・ ・ Management terminal, 406 ・ ・ “Capability evaluation transition” column, 801 ・ ・ Example of rule importance 901 ... Example of rule types 1101 ... Example of quality evaluation criteria 1201 ... Example of ability evaluation transition and correction ability display 1301 ... Example of project evaluation report 1306 ... Change graph 1307 ..Diagnostic result display area for each rule 1401 ··· An example of an evaluation report on sources, 1403 ··· A graph showing the top 10 of poorly rated sources, 1404 · · A diagnostic result display area for each source, 1501 · · · An example of an evaluation report on engineers, 1503 Graph showing the top 10 engineers with poor performance, 1504 ... Diagnosis result display area for each engineer, 1601 ... Example of quality evaluation report for company, 1604 ... Diagnosis result display area for each company, 1701 ... Engineer Example of ability evaluation report for 1705, ... Display area for engineer ability evaluation transition, 1706, ... Change graph of evaluation points, 1707 ..., Diagnostic result display area for each rule, 1801 ... Example of ability evaluation report for company・ 1805 ・ ・ Change graph of evaluation points, 1806 ・ ・ Diagnostic result display area for each engineer, 1901 ・ ・ Example of quality transition report about the project, 1904 ・ ・Quality transition result display area, 2001 ... Example of quality evaluation transition report on source, 2004 ... Source quality transition result display area, 2101 ... Example of quality evaluation transition report on engineer, 2104 ... Quality transition of engineer Result display area, 2201 ・ ・ Example of quality transition report about company, 2204 ・ ・ Quality transition result transition area of company, 2901 ・ ・ Engineer, 2902 ・ ・ Reviewer, 2904 ・ ・ Inspection result report, 2905 ・ ・ Project manager

Claims (5)

In a design development project including a plurality of work processes developed in a distributed development environment composed of a plurality of terminals, a source code evaluation system for evaluating a source code generated for each work process,
Quality inspection means for performing inspection for each generated source code;
A centralized management storage means for centrally managing the inspection result output from the quality inspection means and the engineer information relating to the engineer who created the source code;
Data storage means having rule information relating to the type of defect in the source code and diagnostic history information relating to a result of the inspection performed by the quality inspection means on the source code in the past;
Quality evaluation means for evaluating the quality of the source code and the ability of the engineer to create the source code based on the diagnosis history information and the inspection result output by the quality inspection means,
The quality evaluation means includes
The inspection result information stored in the data storage means is subjected to quality diagnosis for diagnosing the quality of the source code in units of the work process, the source code, and the developer, and the unified management storage means is included in the diagnosis result. A source code evaluation system characterized in that each unit is aggregated and output with reference to The data storage means further includes coding progress information for recording the progress of the source code creation,
The quality inspection means refers to the diagnosis history information, the source inspection means for performing inspection of the source code selected from the list of the source code included in the coding progress information;
The source code evaluation system according to claim 1, further comprising: instruction processing means for causing the source inspection means to execute the inspection periodically. The quality evaluation unit aggregates the inspection result information stored in the data storage unit for each of the rule information, the source code, and the engineer, and determines the number of items detected as defects from the source code. Quality diagnosis means for diagnosing the quality of the source code using the density obtained by dividing the value based on the scale of the source code;
The capability diagnosis means which diagnoses the correction capability as the capability which the said engineer corrects the said malfunction of the said source code based on the diagnostic result of the said quality diagnostic means further, These are characterized by the above-mentioned. Source code evaluation system described in   The quality evaluation means outputs an evaluation report based on the evaluation of the quality of the source code and the ability of the engineer. The evaluation report includes a quality evaluation report for evaluating the quality of the source code, and the quality of the source code. The quality transition report for evaluating the transition of the source code, and the capability evaluation report for evaluating the ability to create the source code are part or all of the report. Source code evaluation system.   The evaluation report is output in a part or all of the engine unit, the source code unit, a company unit to which the engineer belongs, and a software development unit in the design development project. Item 5. The source code evaluation system according to Item 4.

Images