(57)【要約】      （修正有）【課題】ソフトウェア技術者や技術者の属する会社のコーディング能力を客観的に評価することができるソースコード評価システムを提供する。【解決手段】ソースコード評価システム１００は、ソースコード１０３をコーディングした技術者の情報を一元管理するソースコード管理部１０１と、ソースコード１０３のインスペクションを行う品質検査部１０４と、インスペクションなどに必要な各種情報を格納したデータ格納部１１１と、インスペクションの結果と格納されたデータとを分析しソースコード１０３の品質状況と技術者の能力とを評価した評価レポート１１０を出力する品質評価部１０７とを有する。品質評価部１０７はソースコード１０３単位、技術者単位、会社単位、プロジェクト１０２単位でインスペクションおよびソースコードや能力の評価を行う。【選択図】図２
2006059276.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末からなる分散開発環境で開発されている複数の作業工程を含む設計開発プロジェクトにおいて、前記作業工程毎に生成されるソースコードを評価するソースコード評価システムであって、
前記生成されるソースコード毎にインスペクションを行う品質検査手段と、
前記品質検査手段から出力された前記インスペクションの結果と、前記ソースコードを作成した技術者に関する技術者情報を一元管理する一元管理記憶手段と、
前記ソースコードの不具合の種類に関するルール情報および前記品質検査手段が過去に前記ソースコードに対して行った前記インスペクションの結果に関する診断履歴情報を有するデータ格納手段と、
前記診断履歴情報と前記品質検査手段が出力した前記インスペクションの結果をもとに前記ソースコードの品質および前記技術者の前記ソースコードを作成する能力を評価する品質評価手段とを有し、
前記品質評価手段は、
前記データ格納手段に格納されたインスペクション結果情報に対して前記作業工程単位、前記ソースコード単位、開発者単位に前記ソースコードの品質を診断する品質診断を行い、前記診断結果に前記一元管理記憶手段を参照して、それぞれの単位毎に集計し、出力する
ことを特徴とするソースコード評価システム。
【請求項２】
前記データ格納手段は、前記ソースコード作成の経過を記録するコーディング経過情報をさらに有し、
前記品質検査手段は、前記診断履歴情報を参照し前記コーディング経過情報に含まれる前記ソースコードの一覧から選択した前記ソースコードのインスペクションを行うソース検査手段と、
定期的に前記ソース検査手段に前記インスペクションを実行させる命令処理手段と
をさらに備えたことを特徴とする請求項１に記載のソースコード評価システム。
【請求項３】
前記品質評価手段は、前記データ格納手段に格納された前記インスペクション結果情報を、前記ルール情報および前記ソースコードおよび前記技術者ごとにそれぞれ集計し、前記ソースコード中から不具合として検出した項目の数に基づいた値をソースコードの規模で除して得た密度を用いて前記ソースコードの品質を診断する品質診断手段と、
前記品質診断手段の診断結果を元に、前記技術者が前記ソースコードの前記不具合を修正する能力としての修正能力を診断する能力診断手段と
をさらに備えたことを特徴とする請求項１または２に記載のソースコード評価システム。
【請求項４】
前記品質評価手段は前記ソースコードの品質と前記技術者の能力との評価に基づいた評価レポートを出力し、前記評価レポートは、前記ソースコードの品質を評価する品質評価レポート、前記ソースコードの品質の推移を評価する品質推移レポート、前記ソースコードを作成する能力を評価する能力評価レポートのうちの一部または全部であることを特徴とする請求項１から３までのいずれか１項に記載のソースコード評価システム。
【請求項５】
前記評価レポートは前記技術者単位、前記ソースコード単位、前記技術者の所属する会社単位、前記設計開発プロジェクトにおけるソフトウェア開発単位のうちの一部または全部の単位で出力されることを特徴とする請求項４に記載のソースコード評価システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアにおいて、技術者のコーディング能力を評価するソースコード評価システムに関する。
【背景技術】
【０００２】
コンピュータソフトウェア（以下単に「ソフトウェア」と称する）の開発において、複数のプログラム開発を行う技術者が携わる開発を予定通り、履行するために各技術者のコーディング能力を一定水準以上に維持し、かつ向上させる必要があり、そのため各技術者のコーディング能力を随時評価する必要がある。
【０００３】
なお、ここでいうコーディングとは、仕様書やフローチャートなど抽象的な設計文書の内容を、プログラミング言語を用いて具体的なソースコードに翻訳生成する作業を示す。
【０００４】
ソフトウェア開発を行う技術者のコーディング能力を把握する場合、情報処理試験や各種ベンダー試験の資格の有無や、過去に携わった開発業務の内容や年数など開発履歴を参考にする方法が知られているが、資格の有無は技術者のコーディング実務の実力、経験をそのまま示すものではなく、資格があるからといってソースコードを作成できるとは限らない。また、開発履歴は技術者の開発業務開始前の能力しか把握できない。
【０００５】
従来知られている技術では開発作業期間中にインスペクションを行って各技術者の能力を把握し、また能力の向上を図る手法がとられている。ここで、インスペクションとはソースコードに不具合がないかをレビュアー等が解析および検討することを指す。
【０００６】
図２９は従来実施されているインスペクションの業務フローの説明図である。
ソフトウェアの開発のために組まれたソフトウェア開発プロジェクト102において、プログラマなどソフトウェアの開発に従事する技術者（以下単に「技術者」と称する。）2901は仕様書やフローチャートなど抽象的な設計文書の内容をもとにコーディングを行い、プログラミング言語を用いて記述したソフトウェアの設計図となるソースコードを作成する。このソースコード103は、図３０の模式図に示すとおり、プログラミング言語によって作成されたコンピュータに実行させるための命令群である。
【０００７】
また、プロジェクトとはソフトウェア開発のための業務全般を示すものであり、開発するソフトウェアの内容や規模や開発に要する期間などを問わないものとする。
【０００８】
図２９に示すとおり、レビュアー2902はこのソースコード103に対してバグの有無や参照ルールが正しいかどうかを判定するインスペクションを行う。このレビュアー2902とは技術者2901の作成したプログラムの解析検討を業務とする熟練技術者専門家であり（通常は各プログラマの上長）、インスペクションは、各ソースコードをプログラミング言語やプロジェクトごとに設けられた規格や基準によって検討行われる。
【０００９】
レビュアー2902はインスペクションの結果を評価し、評価結果をインスペクション結果レポートとしてまとめる。
【００１０】
図３１にインスペクション結果レポート2904の一例としての模式図を示す。
インスペクション結果レポート2904には「作成者」欄2904Aにレビュアー2902の氏名が、「作成日」欄2904Bにレポート作成日が記載され、「実施内容」欄2904Cにソースコード103の種類やソースファイルの数量などインスペクションの対象や分量を特定する情報が記載される。
【００１１】
「検出項目一覧」表2904Dには、インスペクションを行った日時を記入する「登録日」列2904aと、コーディングが行われたプロジェクト名を記入する「プロジェクト名」列2904bと、ソースコード103を作成した技術者2901の氏名を記入する「技術者」列2904cと、インスペクションの対象としてのソースファイル名を記入する「ソース名」列2904dと、作成されたソースコード103中から検出された不適当と思われる箇所が存在する行番号を記入する「行番号」列2904eと、不適当と思われる根拠を記載する「見直し観点」列2904fとに該当項目が記入される。また、「エラーの傾向と分析」欄2904Ｅには、インスペクションの結果の総括および評価としてソースコード103に確認されたエラーの傾向が記入される。
【００１２】
図２９に示すとおり、レビュアー2902のインスペクションの結果としてのインスペクション結果レポート2904は、ソフトウェア開発プロジェクト102において、プロジェクトの運営・管理に責任を持つプロジェクト管理者2205に通知される。そしてプロジェクト管理者2205はインスペクション結果レポート2904を解析検討し、見つかった不具合を取り除くために、各技術者2901に対しソースコード103の修正指示を出す。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかし、上記のインスペクション結果レポート2904は、レビュアー2902が「指摘項目一覧」表2904Dや「エラーの傾向と分析」欄2904Eに手作業で記載したものを所轄の技術者2901ごとに作成しなければならず、レビュアー2902の負担は大きい。
【００１４】
特に、複数の技術者2901が複数の端末からなる分散開発環境で開発を行う、複数の作業工程を含むような大規模な設計開発プロジェクトにおいては、多数の技術者2901が大量のソースコード103を作成するため、ソースコード103の分量がレビュアー2902の処理能力を超えてしまい、プロジェクト中にインスペクションを継続的に行うことは困難になる場合も多い。
【００１５】
一方、ソースコードによって技術者のコーディング能力を推し図ることは大規模プロジェクトにおいて品質を確保する為に重要な要素であり、現在の技術者のコーディング能力を数値として定量化し、客観的な資料として提示することが求められているが、従来のシステムにおいてはこのような情報提示が可能なシステムは存在しない。
【００１６】
また、大規模プロジェクトにおいてはコーディングをソフトウェア会社に委託することも多く、プロジェクトの委託者側からは、各会社単位でのコーディング能力を客観的に分析するための指標を提供するよう要求があるが、従来のソフトウェア会社について会社単位でのコーディング能力を定量的に分析し判断するための仕組み、体制や具体的なシステムなどは現時点では存在していない。
【００１７】
本発明はこのような事情に鑑みてなされたものであり、ソフトウェア技術者や技術者の属する会社のコーディング能力を客観的に評価することができるソースコード評価システムを提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明に係る上記目的は、複数の端末からなる分散開発環境で開発されている複数の作業工程を含む設計開発プロジェクトにおいて、前記作業工程毎に生成されるソースコードを評価するソースコード評価システムであって、前記生成されるソースコード毎にインスペクションを行う品質検査手段と、前記品質検査手段から出力された前記インスペクションの結果と、前記ソースコードを作成した技術者に関する技術者情報を一元管理する一元管理記憶手段と、前記ソースコードの不具合の種類に関するルール情報および前記品質検査手段が過去に前記ソースコードに対して行った前記インスペクションの結果に関する診断履歴情報を有するデータ格納手段と、前記診断履歴情報と前記品質検査手段が出力した前記インスペクションの結果をもとに前記ソースコードの品質および前記技術者の前記ソースコードを作成する能力を評価する品質評価手段とを有し、前記品質評価手段は、前記データ格納手段に格納されたインスペクション結果情報に対して前記作業工程単位、前記ソースコード単位、開発者単位に前記ソースコードの品質を診断する品質診断を行い、前記診断結果に前記一元管理記憶手段を参照して、それぞれの単位毎に集計し、出力するソースコード評価システムによって達成される。
【発明の効果】
【００１９】
本発明によれば、品質検査手段が技術者の作成したソースコードを自動的に検査し、技術者の作成したソースコードを検査してインスペクションを自動的に行うとともに、品質評価手段がソースコードの品質および品質の推移を確認出来る評価レポートを自動的に作成することができるので、類似のエラーを何度もチェックするレビュアーの作業負担が大幅に軽減できて、中間品質の確認作業の効率化が図れる。
【００２０】
さらに、大量のソースコードのインスペクションや品質の評価を定期的に、また自動的に行うことが可能になるため、大規模プロジェクトに導入することによってソースコードのインスペクションや評価に対するレビュアーの負担を軽減し、大規模プロジェクトにおいても技術者に対するインスペクションを容易に継続的に行うことができる。
【００２１】
さらに、継続的に行われるインスペクション結果に基づき、ソフトウェア技術者や技術者の属する会社単位でのコーディング能力を定量的に分析し判断するための指標を作成することができ、その指標によって各会社のコーディング能力を客観的に評価することができる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の一つの実施の形態について図面を参照して説明する。なお、図面で同一の記号が付された構成およびステップは、同じ構成要件および同じステップを示している。
【００２３】
図１は、本発明の一つの実施の形態に係るソースコード評価システムを用いた、コードインスペクションを示すシステム構成図である。
【００２４】
コードインスペクションシステム100Aは、ソフトウェアを開発するためのプロジェクト（以下単に「プロジェクト」と称する。）102の中で用いられる開発マシン121と、本発明に係るソースコード評価システム100と、管理端末123とを備える。ソースコード評価システム100は、ソースコード管理部101と品質検査部104と品質評価部107とデータ格納部111とを備え、品質検査部104は制御部105とソース検査部106とを有し、品質評価部107は品質診断部108と能力診断部109とを有する。
【００２５】
開発マシン121はプロジェクト102の技術者2901がソースコード103を開発するために用いられる各種コンピュータ端末であって、イントラネット122を介してソースコード評価システム100に接続され、管理端末123はプロジェクト102における管理業務を行うプロジェクト管理者2205が管理業務を行うために用いられる各種コンピュータ端末であり、ＬＡＮ等を介してソースコード評価システム100と接続されている。
【００２６】
このコードインスペクションシステム100Aにおいて、技術者2901は各自の開発マシン121を用いてソースコード103を記述する。開発段階または開発終了後において技術者2901は、イントラネット122を通してソースコード評価システム100のソースコード管理部101にアクセスし、開発したソースコード103と技術者2901の情報を登録する。また、プロジェクト管理者2205は、管理端末123から評価レポート110をダウンロードして内容を検討し、プロジェクト102におけるソースコード103の品質と技術者2901のコーディング能力を確認する。
【００２７】
図２は本発明の一つの実施形態であるソースコード評価システムの構成を示すブロック図である。
ソースコード評価システム100のデータ格納部111は外部記憶装置であり、技術者情報112とコーディング経過情報113と診断履歴情報114とルール情報115とインスペクション結果情報116が格納されている。図3については詳細フローと一緒に後述する。
【００２８】
図４は技術者情報112のデータ構成を示す図である。
技術者情報112はコーディングに携わった技術者2901に関するデータである。
【００２９】
「社員番号」欄401に示される技術者2901の社員番号と、「氏名」欄402に示される技術者2901の氏名と、「会社名」欄403に示される技術者2901の所属する会社名と、「ソース種類」欄404に示されるソースコード103を作成するために用いられたプログラミング言語としてのソース種類と、「プロジェクト数」欄405に示される技術者2901が過去に携わったプロジェクト数と、「能力評価推移」406欄に示される技術者2901の作成したソースコード103に対する評価の推移および修正能力に関するデータによって構成される。なお、「能力評価推移」欄406に表示される能力評価の詳細については後述する。
【００３０】
図５はコーディング経過情報113におけるデータ構成の具体例を示す図である。
コーディング経過情報113はプロジェクト102におけるコーディング経過の概要を記録するデータである。
【００３１】
「プロジェクト名」欄501に示されるソースコード103が作成されたプロジェクト102の名称と、「ソース名」欄502に示されるソースコード103に付けられたソース名と、「更新日時」欄503に示される最新のソースコード103の一覧が作成された日時を年月日時分秒単位で記録した表示と、「ソース種類」欄504に示されるソースコード103のソース種類と、「ステップ数」欄505に示されるソースコード103中に含まれるステップ数と、「社員番号」欄506に示されるソースコード103を作成した技術者2901の社員番号と、「検査日」欄507に示されるソースコード103のインスペクションが行われた日とによって構成される。
【００３２】
図６は診断履歴情報114のデータ構成の具体例を示す図である。
診断履歴情報114は過去にソースコード103に対して行ったインスペクションの結果に関するデータをデータベースとして蓄積したものである。
【００３３】
「プロジェクト名」欄601に示されるソースコード103が作成されたプロジェクト102の名称と、「診断日」欄602に示されるインスペクションが行われた日と、「ソース名」欄603に示されるインスペクションを行ったソースコード103のソース名と、「更新日時」欄604に示される最新のソースコード103の一覧が作成された日時を年月日時分秒単位で記録した表示とによって構成される。なお、「診断日」欄602に表示される診断日とソースコードの検査日とは必ずしも一致するとは限らない。
【００３４】
図７はルール情報115のデータ構成の具体例を示す構成図である。
ルール情報115はインスペクション106において確認が行われるコーディングの不具合の種類のデータを示すものである。
【００３５】
「ルール名」欄701に示される不具合の種類ごとに付された識別記号であるルール名と、「重要度」欄702に示される不具合がシステムに及ぼす影響度を示す重要度と、「ルール種類」欄703に示される不具合のカテゴリとしてのルール種類、「チェック内容」欄704に示される文章で表された不具合の具体的内容とによって構成される。この不具合の具体的内容とは、プログラミング言語でソースコード103を記載する際の間違いや間違いの可能性が高いと考えられる事項であり、たとえばループ内で変数を初期化している等のパフォーマンス上の記載不備や、本文が空のwhile文になっている、ｉｆ条件式の中で代入が行われている等の文法的記載不備などが該当する。
【００３６】
図８は重要度を示す定義テーブルの構成を示す図である。
「重要度」欄702に表示される重要度の定義は定義テーブルとして別途設けられている。定義テーブル801は「重要度」欄801a、「修正の必要」欄801b、「システムの影響」欄801c、「評価ポイント」欄801dを有する。そして、「重要度」欄801aの記載が「最重要」のルールは、必ず修正が必要であり（「修正の必要」欄801bに「必須」と表示される。）、仮に放置した場合、システムに深刻な障害が発生する可能性がある（「システムへの影響」欄801cに「大」と表示される。）不具合を示す。
【００３７】
「重要度」欄801aの記載が「重要」のルールは必ず修正が必要であり、仮に放置した場合、システムに軽度の障害が発生する可能性がある（「システムの影響」）欄801cに「小」と表示される。）不具合を示す。「重要度」欄801aが「警告」のルールは、個別に見て修正が必要であり、仮に放置した場合、システムに深刻な障害が発生する可能性がある不具合を示す。「重要度」欄801aの記載が「通知」のルールは、個別に見て修正が必要であり、仮に放置した場合、システムに軽度の障害が発生する可能性がある不具合を示す。
【００３８】
図９はルール種類の定義を示す定義テーブルの構成を示す図である。
「ルール種類」欄703に表示されるルール種類の定義も定義テーブルとして別途設けられている。
【００３９】
「ルール種類」欄901aに手続型プログラミング言語の代表的な記述ルールが列挙されており、この記述ルールについてのエラーの概要を「内容」欄901bに表示する。コーディングの具体的な不具合に該当するものがルール情報115に読み出される。
【００４０】
図１０はインスペクション結果情報116のデータ構成の具体例を示す図である。
インスペクション結果情報116はインスペクションの結果、抽出された不具合を記録したデータ群を示す。
【００４１】
「プロジェクト名」欄1001に示されるソースコード103が作成されたプロジェクト102の名称と、「ソース名」欄1002に示されるインスペクションを行ったソースコード103のソース名と、「更新日時」欄1003に示される最新のソースコード103の一覧が作成された日時を年月日時分秒単位で記録した表示と、「ルール名」欄1004に示される不具合の種類ごとに付された識別記号であるルール名と、「行番号」欄1005に示されるソースコード103中で不具合が検出された行番号と、「メッセージ」欄1006に示される不具合の具体的内容を文章で表したメッセージと、「検査日」欄1007に示されるインスペクションが行われた日とによって構成される。なお、「メッセージ」欄1006に示されるメッセージは図９の定義テーブルにおける「ルール種類」欄901aの表示に対応するものである。
【００４２】
次に本実施の形態に係るソースコード評価システム100に適用されるソースコード103の品質評価の基準と表示方法について説明する。
【００４３】
図１１は本実施の形態に係るソースコード評価システム100の品質評価基準を示す説明図である。
ソースコード評価システム100は、図８に示すとおり、定義テーブル801の「重要度」欄801aの項目に依存して重み付けされた評価ポイントを「評価ポイント」欄801dに表示するとおりに設定している。インスペクションの結果不具合が検出された全てのソースについて、「ステップ数」欄505に表示された値に「評価ポイント」欄801dに記載された値を重み付け関数として乗じて得た値の総和をソースコード103のキロステップ単位の規模で割った値を評価ポイントと呼び、ポイントが低いほどソースコードの品質が高いことを示す。
【００４４】
図１１では「評価ポイント」欄1101cに示すとおり、０ポイントから３０ポイントまでの評価ポイントが設けられている。一方、この評価ポイントを適当な値ごとに区分けして見やすい記号で表示したものを品質評価記号という。
【００４５】
図１１では評価ポイントを５ポイントごとの合計６区域に区切り、「品質評価記号」欄1101bに示すとおり、０〜５ポイント区域に対して白星５つ、６〜１０ポイント区域に対して白星４つ、・・・２１〜２５ポイント区域に対して白星１つ、２６〜３０ポイント区域に対して黒星１つをそれぞれ品質評価記号として設定し、星の数が多いほど、また黒星よりも白星の方が、ソースコード103の品質が高いことを示している。なお、図１１の具体例においては、「能力評価」欄1101aに示すとおり、「評価ポイント」欄1101cに記載した評価ポイントが０〜１０ポイントのものを能力評価水準Ａ、１１〜２０ポイントのものを能力評価水準Ｂ、２１〜３０ポイントのものを能力評価水準Ｃと設定している。
そして、この能力評価水準に基づく能力評価推移の例を図１２に示す。
【００４６】
図１２は能力評価推移および修正能力の判断基準の模式図である。
図１２において能力は縦軸方向の評価軸（評価ポイント）と横軸方向の時間軸（時間）との相関関係によって評価される。
【００４７】
縦軸はソースコード103の品質に関する確認項目において減点対象ごとに付加されるポイントの数がパラメータであり、能力評価水準Ａ（０ポイント以上１０ポイント未満）、能力評価水準Ｂ（１０ポイント以上２０ポイント未満）、能力評価水準Ｃ（２０ポイント以上３０ポイント未満）の３段階に区分されている。
【００４８】
図１２においてはソースコード103の評価はＡが最高でＣが最低ということになる。一方、横軸はソースコード103の作成に要する日数がパラメータであり、ソース作成開始期間である期間ａ、作成途中期間である期間ｂ、作成終了期間である期間ｃの３期間に区分されている。そして、＋修正能力記号1202aと−修正能力記号1202bとは技術者2901がソースコード103中の不具合を修正する能力としての修正能力（以下単に「修正能力」と称する。）を示したものである。
【００４９】
＋修正能力記号1202aは、当初能力評価水準ＢまたはＣであるソースコード103が短期間で不具合が修正されて能力評価水準Ａになることを示しており、−修正能力記号1202bは当初能力評価水準ＢまたはＣであるソースコード103の不具合が修正されて能力評価水準Ａになるまでに長期間を要するか、または最後まで能力評価水準がＡに至らない状態を示している。
【００５０】
能力評価推移の診断は、次の手順によって行う。まず、開始時と終了時で品質評価が変わらない場合は、能力評価記号をそのまま表示する。たとえば、プロジェクト102の開始時に評価がＡで、終了時の評価がＡの技術者2901は、能力評価推移Ａと診断する。開始時と終了時で品質評価が変わる場合、開始時の評価と終了時の評価を並べて表示する。たとえば、プロジェクト102の開始時に評価がＢで、終了時の評価がＡの技術者2901は、能力評価推移ＢＡと診断する。
【００５１】
次に開始時と終了時で品質評価が変わる場合、次の能力評価基準まで変動した期間を計測する。
【００５２】
本実施の形態においては、説明の簡単のため、能力評価基準Ａに移行する期間の平均が１４日以内であれば＋修正能力記号1202aを、１４日以上かかったか、または最後までＡにならなかった場合は、−修正能力記号1202bを記号の末尾に加えるものとする。なお、本実施の形態においては、説明の簡単のため、ソースコード103の作成が開始されてから１４日経過時と２８日経過時にインスペクションを行い、先のインスペクションにおける評価と後のインスペクションにおける評価を対比することで能力評価推移および修正能力を判断するものとする。
【００５３】
図１２は上述の基準に基づいて作成されたに能力評価推移および修正能力の判断基準の模式図である。上述の基準に基づいて作成された技術力評価推移および修正能力の判断基準例が示されている。
【００５４】
第１評価例1201aはコーディングの開始後１４日経過時に技術力評価水準Ａに達しているので「Ａ」とのみ評価され＋修正能力記号1202aも−修正能力記号1202bも表示されないことになる。
【００５５】
第２評価例1201bおよび第３評価例1201cはコーディングの開始後１４日経過時に技術力評価水準Ｂだったものが２８日経過後に技術力評価水準Ａに達しているので、技術力評価推移「ＢＡ」と評価され、＋修正能力記号1202aが表示される。
【００５６】
第３評価例1201cはコーディングの開始後１４日経過時に技術力評価水準Ｃだったものが２８日経過時に技術力評価水準Ａに到達しているので、技術力評価推移「ＣＡ」と評価され、＋修正能力記号1202aが表示される。
【００５７】
第４評価例1201dはコーディングの開始後１４日経過後よりも２８日経過後の方が評価ポイントは向上しているものの２８日経過時に技術力評価水準Ａに到達していないので、技術力評価推移「ＣＢ」と評価され、−修正能力記号1202bが表示される。
【００５８】
第５評価例1201eはコーディングの開始後１４日経過時と２８日経過時のいずれも技術力評価水準Ｂのままであり、技術力評価推移「ＢＢ」と評価されて、−修正能力記号1202bが表示される。
【００５９】
図４の「技術力評価推移」欄406に示された表記は上記例で示すコーディングの技術力評価推移およびソースコード103の修正能力を表示したものである。
【００６０】
なお、本実施の形態におけるインスペクションの回数および間隔は例示であり、実施の態様に応じ、インスペクションは２回より多く行われてもよく、また、インスペクションの間隔は１４日より長くても短くてもよい。
【００６１】
図３は、図２に示すソースコード評価システム100の接続構成を示すデータ構成図である。
【００６２】
以下、本図を参照して本実施の形態に係るソースコード評価システム100の各部の動作を説明する。
【００６３】
ソースコード管理部101は、ソースコード103を読み込む。このとき、ソースコード103に含まれるプロジェクトに関する情報や技術者2901の氏名などの情報も併せてソースコード管理部101に読み込まれて登録され、ソースコード103を作成した技術者2901の技術者情報112がソースコード管理部101に読み込まれる。なお、登録された情報は技術者情報112やコーディング経過情報113に格納される。
【００６４】
ソースコード管理部101は複数のプロジェクト102単位でソースコード103を管理するため、技術者2901がいくつかのプロジェクト102にまたがって開発をしていた場合であってもインスペクションの対象としてのソースコード103を取得することができる。なお、このソースコード103は、図３０の模式図に示す態様のものである。
【００６５】
ソースコード管理部101からコーディング経過情報113に対し、技術者2901とソースコード名の対応付けが出力される。
【００６６】
制御部105は、定期的にコーディング経過情報113として格納された各プロジェクト102ごとの情報を調査し、新規に登録されたソースコード103の一覧を作成する。そして、制御部105は、コーディング経過情報113を読み込んでソースコード103を取得する。制御部105が取得したソースコード103はソース検査部106に送られて、ソース検査部106は受け取ったソースコード103についてインスペクションを行う。制御部105は、診断したソースコード103について診断履歴情報114を出力する。ソース検査部106は、プロジェクト102毎に指定されたルール情報115を読み込んでソースコード103についてインスペクションを行い、結果を出力する。インスペクションの結果はインスペクション結果情報116において登録されて蓄積される。
【００６７】
インスペクション結果情報116は品質診断部108に読み込まれ、品質診断部108は、読み込んだインスペクション結果情報116における各不具合について、図８に示す定義テーブル801に基づいて修正の必要とシステムへの影響に鑑みた重要度を判断し、「重要度」欄801aの定義に基づいて「評価ポイント」欄801dに規定された評価ポイントを評価ポイント変数とする。品質診断部108はこの評価ポイント変数をソースコード103の規模（ステップ数）で除した値を評価ポイントとして算出する。品質診断部108はこの評価ポイントを図８に示すルールごと、ソースコード103ごと、技術者2901ごとに集計して評価レポート110として出力する。
【００６８】
品質診断部108はインスペクション結果情報116を能力診断部109にも出力し、能力診断部109は、プロジェクト102の終了時に、各技術者2901が各プロジェクト102において作成したソースコード103が所望の品質に収束するまでにどの程度の期間を要したか等に関する過去の評価の推移を技術者2901ごとに分析し、コーディングの能力の評価推移およびソースコード103の修正能力を算出して技術者情報112を更新し、処理を最初から繰り返す。技術者情報112に保存された前述の各種情報は、データ化することにより、次のプロジェクト102を行う際に各技術者2901が所望の品質のソースコード103を書くことができるのか、および所望の品質のソースコード103を書くまでにどの程度の期間を要するかを判断するための指標として用いることができる。
【００６９】
ソースコード評価システム100は評価レポート110を電子情報として出力し、管理端末123のディスプレイに表示する。
【００７０】
以下、本発明の実施の一形態であるソースコード評価システム100から出力される評価レポート110の例について図１３を参照して説明する。
【００７１】
図１３はプロジェクト102に関する品質評価レポート1301の帳票レイアウトを示す図である。
品質評価レポート1301はタイトル表示部1302と、インスペクションによってソースコード103が診断された日を表示する診断日表示部1303と、ソースコード103が作成されたプロジェクト102の名称を表示するプロジェクト名表示部1304と、プロジェクト情報表示領域1305と、評価ポイントの推移グラフ1306と、診断結果の概要をルール単位で表示する診断結果表示領域1307とで構成されている。
【００７２】
プロジェクト情報表示領域1305には、インスペクションおよび評価の対象となったプロジェクト102の品質評価および評価値を図１２に示された基準に基づいて表示する品質評価および評価値表示部1305aが設けられ、その他に評価対象のプロジェクト102におけるソース数や、キロステップ単位で表示したソースコード103の規模や、技術者2901の数や、評価結果における検出された不具合の数の合計や重要度ごとの不具合の検出件数が表示される。
【００７３】
診断結果表示領域1307においては、「ルール名」欄1307aにルール名、「重要度」欄1307bに定義テーブル801で定義された重要度、「ルール種類」欄1307cに定義テーブル901の「ルール種類」欄901aで定義されたルール種類、「検出内容」欄1307dに不具合として検出された定義テーブル901の「内容」欄901bで定義されたルールの内容、「検出数」欄1307eに検出された不具合の集計結果、「ソース数」欄1307fに不具合として検出されたソースコード数の集計結果が、「人数」欄1307gに不具合を作成したとして検出された技術者2901の集計結果が、それぞれルール単位で表示される。
【００７４】
図１４はソースコードに関する品質評価レポート1401の帳票レイアウト例を示す説明図である。
品質評価レポート1401はタイトル表示部1402と、診断日表示部1303と、プロジェクト名表示部1304とプロジェクト情報表示領域1305と、評価グラフ1403と、診断結果の概要をソース単位で表示する診断結果表示領域1404とで構成されている。
【００７５】
診断結果表示領域1404においては、「ソース名」欄1404aにソース名、「更新日」欄1404bに更新日、「氏名」欄1404cに技術者2901の氏名、「評価」欄1404dに図１１で定義した品質評価記号、「評価Ｐ」記載欄1404eに図１１で定義した評価ポイント、「規模」欄1404fにはソース規模が、「ルール」欄1404g、1404g、・・・にはルールごとに検出された不具合の数、「合計」欄1404hには検出された不具合の数の合計、「必須」欄1404iには必ず直さねばならない不具合（図７の「重要度」欄702に表示された定義中「最重要」および「重要」に該当する不具合）の検出数の和、「個別」欄1404jには個別に直すべき不具合（図７の「重要度」欄702に表示された定義中「警告」および「通知」に該当する不具合）の検出数の和が、それぞれ表示される。
【００７６】
評価グラフ1403には「評価Ｐ」、記載欄1404eの評価ポイントが高いソースのうち上位１０ソースまでが「評価ワースト１０」として棒グラフで表示される。グラフの単位は「評価Ｐ」記載欄1404eと同じ評価ポイントである。
【００７７】
図１５は管理端末123のディスプレイに表示される、技術者2901に関する品質評価レポート1501の帳票レイアウト例を示す説明図である。
【００７８】
品質評価レポート1501はタイトル表示部1502と診断日表示部1303とプロジェクト名表示部1304と、プロジェクト情報表示領域1305と評価が悪い技術者2901の上位１０名までの評価を示す評価グラフ1503と診断結果の概要を技術者2901単位で表示する診断結果表示領域1504とで構成されている。
【００７９】
診断結果表示領域1504にはそれぞれ以下の内容が表示される。
「技術者」欄1504aには技術者2901の氏名、「会社名」欄1504bには技術者2901の所属する会社名、「評価」欄1504cには図１１で定義した品質評価記号、「評価Ｐ」欄1504dには図１１で定義した評価ポイント、「規模」欄1504eにはソース規模、「ルール」欄1504f、1504f、・・・にはルールごとの不具合の検出数が「合計」欄にそれぞれ表示される。
【００８０】
1504gには不具合の検出数の合計が表示され、「必須」欄1504hには図７の「重要度」欄702に表示された定義中「最重要」と「重要」に該当する不具合の検出数の和が表示される。
【００８１】
「個別」欄1504iには図７の「重要度」欄702に表示された定義中「警告」および「通知」に該当する不具合の検出数の和が表示され、「前回の評価推移」欄1504ｊには前回のプロジェクト102における能力評価推移および修正能力がそれぞれ表示される。
【００８２】
評価グラフ1503には「評価Ｐ」記載欄1504dの評価ポイントが高い技術者2901のうち上位１０人までの評価が「評価ワースト１０」として棒グラフで表示される。
【００８３】
図１６は、管理端末123のディスプレイに表示される、会社に関する品質評価レポート1601の帳票レイアウト例を示す説明図である。
【００８４】
品質評価レポート1601はタイトル表示部1602と診断日表示部1303とプロジェクト名表示部1304とプロジェクト情報表示領域1305と、評価が悪い会社のトップ１０を示すグラフ1603と、診断結果の概要を技術者2901それぞれの所属する会社単位で表示する診断結果表示領域1604とで構成されている。
【００８５】
「会社名」欄1604aには技術者2901それぞれが所属する会社名、「評価」欄1604bには図１１で定義した品質評価記号、「評価Ｐ」欄1604cには図１１で定義した評価ポイント、
「規模」欄1604cにはソース規模が、「ルール」欄1604e、1604e、・・・にはルールごとに検出された不具合の数がそれぞれ表示される。
【００８６】
さらに「合計」欄1604fには不具合の検出数の合計、「必須」欄1604gには図７の「重要度」欄702に表示された定義中「最重要」と「重要」に該当する不具合の検出数の和、
「個別」欄1604hには図７の「重要度」欄702に表示された定義中「警告」および「通知」に該当する不具合の検出数の和、「前回の評価推移」欄1604iには前回のプロジェクト102における能力評価推移および修正能力が、それぞれ表示される。
【００８７】
グラフ1603には「評価Ｐ」記載欄1604cの評価ポイントが高い会社のうち上位１０社までの評価が「評価ワースト１０」として棒グラフで表示される。
【００８８】
本実施の形態においてはソースコード103の品質に加え、ソースコード103を開発する技術者2901や技術者2901の所属する会社のコーディング能力の評価を行うこともできる。
【００８９】
図１７は技術評価レポート1701の帳票レイアウト例を示す説明図である。
管理端末123のディスプレイに表示される、技術者2901に関する技術評価レポート1701のレイアウトは以下の項目で構成されている。
【００９０】
能力評価レポート1701はタイトル表示部1702と診断日表示部1303と、技術者名および会社名表示部1703と技術者情報表示領域1704と、能力評価推移表示領域1705と、評価ポイントの推移を示す推移グラフ1706と、ルールごとの診断結果表示領域1707とで構成されている。
【００９１】
技術者情報表示領域1704にはプロジェクト情報表示領域1305と同様の項目が表示され、能力評価推移表示領域1705には前回のプロジェクト102における能力評価推移および修正能力が表示され、図７に定義されたルール種類のうち不具合としての検出数が最も多いものトップ３が「要注意分野」として出力される。
【００９２】
推移グラフ1706において縦軸が評価ポイントであり、横軸がインスペクションを行った日付を指す。
技術者名および会社名表示部1703に表示された技術者2901の日ごとの評価ポイントの推移が折れ線グラフで表示される。
【００９３】
診断結果表示領域1707において、「ルール名」欄1707aにルール名、「重要度」欄1707bに図８で定義された重要度、「種類」欄1707cには図８で定義されたルール種類、「チェック内容」欄1707dには図９で定義されたルールの内容、「検出数」欄1707eには検出された不具合の数の合計、「ソース数」欄1707fには不具合として検出されたソースコードの数がそれぞれ表示される。
【００９４】
図１８は、能力評価レポート1801の帳票レイアウト例を示す説明図である。
管理端末123のディスプレイに表示される、会社に関する能力評価レポート1801のレイアウトは以下の項目で構成されている。
【００９５】
タイトル表示部1802と、診断日表示部1303と、会社名表示部1803と、会社情報の表示領域1804と、評価ポイントの推移グラフ1805と診断結果の概要を技術者2901単位で表示する診断結果表示領域1806とで構成されている。
【００９６】
推移グラフ1805には縦軸には評価ポイントが指標となり、横軸はインスペクションを行った日付が指標となる。
【００９７】
会社名表示部1803に表示された会社の評価ポイントの推移が折れ線グラフで表示される。
【００９８】
「技術者名」欄1806aにソースコードの作成を行った技術者2901の名、「重要度」欄1806bに図８で定義された重要度、「評価Ｐ」欄1806dには図１１で定義した評価ポイント、「規模」欄1806eにはソース規模、「ルール」欄1806e、1806e、・・・にはルールごとに検出された不具合の数、「合計」欄1806fには検出された不具合の数の合計、「必須」欄1806gには図７の「重要度」欄702に表示された定義中「最重要」および「重要」に該当する不具合の検出数の和、「個別」欄1806hには図７の「重要度」欄702に表示された定義中「警告」および「通知」に該当する不具合の検出数の和、「前回の評価推移」欄1806iには前回のプロジェクト102における能力評価推移および修正能力がそれぞれ表示される。
【００９９】
図１９はプロジェクト102に関する品質推移レポート1901の帳票レイアウト例を示す説明図である。
【０１００】
管理端末123のディスプレイに表示される、プロジェクト102に関する品質推移評価レポート1901は、タイトル表示部1902とプロジェクト名表示部1903とプロジェクトの品質推移結果表示領域1904によって構成される。
【０１０１】
「日付」欄1904aにはインスペクションが行われた日付、「評価」欄1904bには図１１で定義した品質評価記号、「評価Ｐ」欄1904cには図１１で定義した評価ポイント、「規模」欄1904dにはソース規模、「ルール」欄1904e、1904e、・・・にはルールごとの不具合の検出数、「合計」欄1904fには不具合の検出数の合計、「必須」欄1904gには図７の「重要度」欄702に表示された定義中「最重要」と「重要」に該当する不具合の検出数の和、個別」欄1904hには図７の「重要度」欄702に表示された定義中「警告」および「通知」に該当する不具合の検出数の和、「推移」欄1904iには「個別」欄1904h欄に表示された不具合の検出数を５０個単位で黒四角に表示するとともに「必須」欄1904gに表示された不具合の検出数を５０個単位に白四角で表示して不具合の検出数の概数をあらわしたグラフが、それぞれ表示される。
【０１０２】
図２０はソースに関する品質推移レポート2001の帳票レイアウト例を示す説明図である。管理端末123のディスプレイに表示される品質推移レポート2001は、タイトル表示部2002とソース名表示部2003とソースの品質推移結果表示領域2004とで構成される。
【０１０３】
品質推移結果表示領域2004の「日付」欄2004a、「評価」欄2004b、「評価Ｐ」欄2004c、「規模」欄2004d、「ルール」欄2004e、2004e、・・・、「合計」欄2004f、「必須」欄2004g、「個別」欄2004h、「推移」欄2004iの表示内容は、図１９に示すプロジェクトに関する評価レポート1901における品質推移結果表示領域1904の表示内容と同じである。
【０１０４】
図２１は技術者2901に関する品質推移レポート2101の帳票レイアウト例を示す説明図である。
管理端末123のディスプレイに表示される品質推移レポート2101は、タイトル表示部2102と技術者名および会社名表示部2103と技術者2901の品質推移結果表示領域2104とで構成されている。
【０１０５】
品質推移結果表示領域2104の「日付」欄2104a、「評価」欄2104b、「評価Ｐ」欄2104c、「規模」欄2104d、「ルール」欄2104e、2104e、・・・、「合計」欄2104f、「必須」欄2104g、「個別」欄2104h、「推移」欄2104iの表示内容は、図１９に示すプロジェクトに関する評価レポート1901における品質推移結果表示領域1904の表示内容と同じである。
【０１０６】
図２２は技術者2901に関する品質推移レポート2201の帳票レイアウト例を示す説明図である。
管理端末123のディスプレイに表示される品質推移レポート2201はタイトル表示部2202と会社名表示部2203と会社の品質推移結果表示領域2204とで構成されている。
【０１０７】
そして、品質推移結果表示領域2204の「日付」欄2204a、「評価」欄2204b、「評価Ｐ」欄2204c、「規模」欄2204d、「ルール」欄2204e、2204e、・・・、「合計」欄2204f、「必須」欄2204g、「個別」欄2204h、「推移」欄2204iの表示内容は、図１９に示すプロジェクトに関する評価レポート1901における品質推移結果表示領域1904の表示内容と同じである。
【０１０８】
図２３はソースコード評価システムのソースコード管理部におけるソース管理機能の処理の流れを示すフローチャートである。
【０１０９】
以下、このフローチャートに基づいてソースコード管理部101のソース管理のための処理動作を説明する。
【０１１０】
ソースコード管理部101は開発マシン121のディスプレイに、アクセスした技術者2901にプロジェクト102の名称と社員番号を入力するよう促す画面を表示し（ステップ2301）、ソースコード管理部101は、開発マシン121に技術者2901が入力したプロジェクト102の名称のデータを取得し（ステップ2302）、社員番号のデータを取得する（ステップ2303）。
【０１１１】
プロジェクト102の名称と社員番号を取得するとソースコード管理部101は、開発マシン121のディスプレイに技術者2901が作成した最新のソースコード103を入力するように促す画面を表示し、技術者2901が入力した最新のソースコード103を取得する（ステップ2304）。
【０１１２】
次にソースコード管理部101は取得したソースコード103のファイル名と最終更新日時を調べる（ステップ2305）。ソースコード管理部101はソースコードのファイル名の拡張子からソースコードの種類を判別する（ステップ2306）。
【０１１３】
ソースコード管理部101はソースコードの行数を計測する（ステップ2307）。ソースコード管理部101はデータ格納部111のコーディング経過情報113の、「プロジェクト名」欄501、「ソース名」欄502、「ファイルの更新日時」欄503、「ソース種類」欄504、「ステップ数」欄505、「社員番号」欄506に取得したソースコード103を挿入し登録する（ステップ2308）。
【０１１４】
図２４はソースコード評価システム100の制御部105における命令処理機能の処理の流れを示すフローチャート図である。
【０１１５】
以下、このフローチャートに基づいて制御部105の命令処理の動作を説明する。
【０１１６】
制御部105はインスペクションの実行時間になると定期的に起動し（ステップ2401）、実行中にエラーが発生した場合に備えて実行環境をバックアップする（ステップ2402）。
【０１１７】
制御部105はソースコード103をコンパイルするのに必要となるライブラリやモジュール等のコンパイル環境を読み込む（ステップ2403）。
【０１１８】
制御部105はインスペクションにおける検討の規則として、プロジェクト102の状態にあったルールモジュールを選択し設定する（ステップ2404）。制御部105は、コーディング経過情報113を検索し、蓄積されたソースコード103について最新のソースコード103の一覧を作成する（ステップ2405）。
【０１１９】
制御部105は現在の日付を調べ、診断履歴情報114にインスペクション対象とするソースコードのデータとして「プロジェクト名」欄601のプロジェクト名、「診断日」欄602の診断日、「ソース名」欄603のソース名、「更新日時」欄604に表示されたソースファイルの最終更新日時を挿入する（ステップ2406）。次に、制御部105は最新のソースコード103を読み込み（ステップ2407）、コンパイルする（ステップ2408）。
【０１２０】
制御部105は最新のソースコード103の一覧から、前回の診断以降に更新されているファイルを選択する（ステップ2409）。制御部105は、前回の診断以降に更新されているファイルにおいて、インスペクション対象外とされている部分に目印をつけるためフィルタリングする（ステップ2410）。
【０１２１】
制御部105はソース検査部106を呼び出し、インスペクションを実行する（ステップ2411）。制御部105は品質診断部108を呼び出し、インスペクションの結果を集計し、評価をつける（ステップ2412）。
【０１２２】
制御部105は能力診断部109を呼び出し、コーディングの能力評価推移およびソースコード103の修正能力を分析し、評価レポート110を出力する。
【０１２３】
図２５はソースコード評価システム100のソース検査部106におけるインスペクション機能の処理の流れを示すフローチャート図である。
【０１２４】
以下、このフローチャートに基づいてソース検査部106の動作を説明する。
【０１２５】
ソース検査部106はインスペクションの規則として設定されているルールモジュールを読み込む（ステップ2501）。ソース検査部106は、ソースコード評価システム100を構成するハードウェアのマシンスペックに基づいて、一度に解析するソースコード103の数を決定する（ステップ2502）。
【０１２６】
ソース検査部106は、解析対象のソースコード103を幾つかのソースコード103のセットにまとめる（ステップ2503）。ソース検査部106は、全てのソースコード103のセットについて一つずつ（ステップ2504）、全てのソースコード103のセットについて実行するまで（ステップ2519）、ステップ2505からステップ2518までを実行する。
【０１２７】
ソース検査部106は、全てのソースコード103について一つずつ（ステップ2505）、全てのソースコード103について実行するまで（ステップ2518）、ステップ2506からステップ2517までを実行する。
【０１２８】
ソース検査部106はソースコード103を読み込み、コーディング経過情報113の対応するソースコード103の「検査日」欄507に現在日を挿入する（ステップ2506）。ソース検査部106は読み込んだソースコード103から構文木を生成する（ステップ2507）。ソース検査部106はファイルの内容を解析し、構文木に対応するファイル情報を生成する（ステップ2508）。ソース検査部106は、対応するソースコード103の中で呼ばれているネイティブコード読み込む（ステップ2509）。
【０１２９】
次に、ソース検査部106は、ネイティブコードを解析し、変数や関数についての基本情報を生成する。ネイティブコードが読み込めなかった場合、リフレクションを使用し、同等の情報を生成する（ステップ2510）。ソース検査部106は、登録されているルールにつき一つずつ（ステップ2511）、全てのルールについて実行するまで（ステップ2517）、ステップ2512からステップ2516までを実行する。ソース検査部106は、構文木を辿るプログラムを走らせ、構文木のトークンについて一つずつ（ステップ2512）、全てのトークンを辿るまで（ステップ2516）、ステップ2513からステップ2515までを実行する。
【０１３０】
ソース検査部106は読み込んだルールモジュールを実行し、インスペクションの確認内容に引っ掛かったか判定する（ステップ2513）。
【０１３１】
ソース検査部106は、井インスペクションの結果が正の場合、そのコードが記述されている行番号がインスペクション対象外としてフィルタリングされているか判定する（ステップ2514）。次に、ソース検査部106は、判定結果が否の場合、チェック結果（ステップ2515）をデータ格納部111のインスペクション結果情報116に出力し蓄積する。
【０１３２】
図２６は本実施の形態におけるソースコード評価システム100の品質診断部108におけるデータ分析機能の分析処理および品質評価処理の流れを示すフローチャートである。
【０１３３】
以下、このフローチャートに基づいて品質管理部108のデータ分析処理および品質評価処理について説明する。
【０１３４】
品質管理部108はプロジェクト102の診断履歴情報114を読み込む（ステップ2601）、品質管理部108は「プロジェクト名」欄601に表示されたプロジェクト名と「ソース名」欄603に表示されたソース名と「更新日時」欄604に表示された更新日時に対応するソースのインスペクション結果情報116を全て読み込む（ステップ2602）。品質管理部108はコーディング経過情報113から対応するソースのデータを読み込む（ステップ2603）。
【０１３５】
技術者情報112から対応する技術者2901のデータを読み込む（ステップ2604）。
品質管理部108はルール情報115を読み込む（2605）。品質管理部108は診断結果につき一つずつ（ステップ2606）、全ての日付を辿るまで（ステップ2619）、ステップ2609からステップ2608までを実行する。
【０１３６】
品質管理部108は診断日に一致するソース一覧を取得する（ステップ2607）。品質管理部108は、ソース一覧に対応するインスペクション結果情報116を取得し、以上のデータを結合し１レコードとしたコレクションを生成する（ステップ2608）。
【０１３７】
品質管理部108はコレクションをプロジェクト102全体で集計する（ステップ2609）。品質管理部108はコレクションをルールごとに集計する（ステップ2610）。品質管理部108はコレクションをソースごとに集計する（ステップ2611）。品質管理部108はコレクションを技術者2901ごとに集計する（ステップ2612）。品質管理部108はコレクションを所属会社ごとに集計する（ステップ2613）。
【０１３８】
品質管理部108は更新日付が最新のものか判定する（ステップ2614）。品質管理部108はステップ2614の結果が正であった場合、評価が最も悪いソースを１０個選択する（ステップ2615）。
【０１３９】
品質管理部108は評価が最も悪い技術者2901を１０人選択する（ステップ2616）、品質管理部108は評価が最も悪い会社を１０社選択する（ステップ2617）。ステップ2605の判定結果が負の場合には、品質管理部108は特段の処理は行わない。なお、ステップ2615、ステップ2616、ステップ2617においてそれぞれの評価の悪いものを選択するときの選択個個数は任意に設定することができる。
【０１４０】
品質管理部108はプロジェクト102に関する品質評価レポート1301を出力し（ステップ2619）、品質管理部108はソースに関する品質評価レポート1401を出力する（ステップ2620）。
【０１４１】
品質管理部108は技術者2901に関する品質評価レポート1501を出力し（ステップ2621）、品質管理部108は会社に関する品質評価レポート1601を出力する（ステップ2622）。
【０１４２】
品質管理部108は技術者2901に関する能力評価レポート1701を出力する（ステップ2623）。そして、品質管理部108は会社に関する能力評価レポート1801を出力する（ステップ2624）。
【０１４３】
品質管理部108はプロジェクト102に関する品質推移レポート1901を出力する（ステップ2625）。品質管理部108はソースに関する品質推移レポート2001を出力する（ステップ2626）。品質管理部108は技術者2901に関する品質推移レポート2101を出力する（ステップ2627）。品質管理部108は会社に関する品質推移レポート2201を出力する（ステップ2628）。
【０１４４】
図２７は、本実施の形態に係るソースコード評価システム100の品質診断部108におけるデータ集計機能の集計処理の流れを示すフローチャートである。
以下、品質診断部108のデータ集計処理の詳細をフローチャートに従って説明する。
【０１４５】
品質診断部108はコレクションに含まれるインスペクション結果情報116のデータレコード数を取得する（ステップ2701）。品質診断部108は必須変数と個別変数とルールごとの変数を用意し、値を０に初期化する（ステップ2702）。必須変数とは図８に示す「修正の必要」欄801bにおいて修正の必要が「必須」と定義された項目を変動させる関数であり、個別変数とは図８に示す「修正の必要」欄801bにおいて「個別」と定義された項目を変動させる関数である。次に、品質診断部108は評価ポイントを格納する評価ポイント変数を用意し、値を０に初期化する（ステップ2703）。次に、品質診断部108はステップ数を格納するステップ数変数を用意し、値を０に初期化する（ステップ2704）。品質診断部108はコレクションに含まれる全てのデータに対して一つずつ（ステップ2705）、全てのデータについて実行するまで（ステップ2712）、ステップ2706からステップ2711までの処理を実行する。
【０１４６】
品質診断部108はルールに対応する変数を１繰り上げる（ステップ2706）。品質診断部108はインスペクション結果情報116のルールＩＤからルールの重要度を検索する（ステップ2707）。品質診断部108はルールの重要度が最重要か又は重要であるか判定する（ステップ2708）。
【０１４７】
ステップ2708の判定結果が正である場合、品質診断部108は必須変数を１繰り上げる（ステップ2709）。ステップ2708の判定結果が負である場合、品質診断部108は個別変数を１繰り上げる（ステップ2710）。
【０１４８】
品質診断部108はルールの重要度と対応する評価ポイントを評価ポイント変数に加算する（ステップ2711）。品質診断部108はコレクションに含まれる技術者2901の数を技術者変数に代入する（ステップ2713）。品質診断部108はコレクションに含まれる会社の数を会社変数に代入する（ステップ2714）。品質診断部108はコレクションに含まれる全てのソースに対して一つずつ（ステップ2715）、全てのソースについて実行するまで（ステップ2717）、ステップ2716の処理を実行する。
【０１４９】
品質診断部108はソースの規模をステップ数変数に加算する（ステップ2716）。品質診断部108はソース変数にソースの数を代入する（ステップ2718）。品質診断部108は評価ポイント変数に対しステップ数変数によって除算を行い、得られた値を評価ポイント変数に代入する（ステップ2719）。
【０１５０】
図２８は本実施の形態に係るソースコード評価システム100の能力評価部109における能力評価機能の処理の流れを示すフローチャートである。
以下、このフローチャートに基づいて能力評価部109の能力評価処理を説明する。
【０１５１】
能力評価部109は、プロジェクト102の終了時のみ、以降の処理を行う。能力評価部109は、プロジェクト102の期間中で最初の技術者2901の品質評価ポイントを取得し、対応する能力評価を算出する（ステップ2801）。
【０１５２】
能力評価部109は、プロジェクト102の開発期間中で最後の技術者2901の品質評価ポイントを取得し、対応する能力評価を算出する（ステップ2802）。能力評価部109は最初と最後の能力評価が一致するか判定する（ステップ2803）。ステップ2803の判定結果が正の場合、能力評価部109は最初の能力評価を最終能力評価とし（ステップ2804）、技術者情報112の「社員番号」欄401に表示される社員番号と「ソース種類」欄404に表示されるソース種類と「能力評価推移」欄406に表示される能力評価推移および修正能力を更新し、プロジェクト数を１加算する（ステップ2812）。
【０１５３】
一方、ステップ2803の判定結果が負の場合、能力評価部109は、最初と最後の能力評価記号を並べるとともに−修正能力記号1202bを表示する（ステップ2805）。
【０１５４】
能力評価部109はプロジェクト102の期間中で最初に技術者2901の評価ポイントが変化した診断日を調べる（ステップ2806）。能力評価部109はプロジェクト102の期間中で技術者2901の能力評価がＡに変化した診断日を調べる（ステップ2807）。能力評価部109はステップ2807の診断日からステップ2806の診断日を引き変動期間を調査する（ステップ2808）。
【０１５５】
能力評価部109は、変動期間が１４日以内か判定する（ステップ2809）。ステップ2810の判定結果が正の場合、能力評価部109は能力評価記号の後ろに＋修正能力記号1202aを表示する。一方、ステップ2810の判定結果が負の場合、能力評価部109は能力評価記号の後ろに−修正能力記号1202bを表示する。そして、能力評価部109はステップ2812を実行する。
【図面の簡単な説明】
【０１５６】
【図１】本発明の一の実施の形態におけるソースコード評価システムを用いたコードインスペクションシステムのシステム構成図である。
【図２】同上ソースコード評価システムの構成を示すブロック図である。
【図３】同上ソースコード評価システムの処理フローを示すフロー図である。
【図４】同上ソースコード評価システムの技術者情報のデータ構成を示す説明図である。
【図５】同上ソースコード評価システムのコーディング経過情報のデータ構成を示す説明図である。
【図６】同上ソースコード評価システムの診断履歴のデータ構成を示す説明図である。
【図７】同上ソースコード評価システムのルール情報のデータ構成を示す説明図である。
【図８】同上ソースコード評価システムにおけるルールの重要度を示す説明図である。
【図９】同上ソースコード評価システムにおけるルールの種類を示す説明図である。
【図１０】同上ソースコード評価システムのインスペクション結果情報のデータ構成を示す説明図である。
【図１１】同上ソースコード評価システムの品質評価基準を示す説明図である。
【図１２】同上ソースコード評価システムの能力評価推移および修正能力の表示例を示す説明図である。
【図１３】同上ソースコード評価システムのプロジェクトに関する品質評価レポートの帳票レイアウト例を示す説明図である。
【図１４】同上ソースコード評価システムのソースに関する品質評価レポートの帳票レイアウト例を示す説明図である。
【図１５】同上ソースコード評価システムの会社に関する品質評価レポートの帳票レイアウト例を示す説明図である。
【図１６】同上ソースコード評価システムの会社に関する品質評価レポートの帳票レイアウト例を示す説明図である。
【図１７】同上ソースコード評価システムの技術者に関する技術評価レポートの帳票レイアウト例を示す説明図である。
【図１８】同上ソースコード評価システムの会社に関する能力評価レポートの帳票レイアウト例を示す説明図である。
【図１９】同上ソースコード評価システムのプロジェクトに関する品質推移レポートの帳票レイアウト例を示す説明図である。
【図２０】同上ソースコード評価システムのソースに関する品質推移レポートの帳票レイアウト例を示す説明図である。
【図２１】同上ソースコード評価システムの技術者に関する品質推移レポートの帳票レイアウト例を示す説明図である。
【図２２】同上ソースコード評価システムの会社に関する品質推移レポートの帳票レイアウト例を示す説明図である。
【図２３】同上ソースコード評価システムのソースコード管理部におけるソース管理機能の処理の流れを示すフローチャートである。
【図２４】同上ソースコード評価システムの制御部における命令処理機能の処理の流れを示すフローチャートである。
【図２５】同上ソースコード評価システムのソース検査部におけるインスペクション機能の処理の流れを示すフローチャートである。
【図２６】同上ソースコード評価システムの品質診断部における品質診断機能の処理の流れを示すフローチャートである。
【図２７】同上ソースコード評価システムの品質診断部におけるデータ集計機能の処理の流れを示すフローチャート図である。
【図２８】同上ソースコード評価システムの能力診断部における能力診断機能の処理の流れを示すフローチャートである。
【図２９】従来のインスペクションにおける業務フローを説明した説明図である。
【図３０】従来のインスペクションにおいて評価の対象となるソースコードの模式図である。
【図３１】従来のインスペクションの結果の例を示す模式図である。
【符号の説明】
【０１５７】
100・・ソースコード評価システム、101・・ソースコード管理部、102・・プロジェクト、103・・ソースコード、104・・品質検査部、105・・制御部、106・・ソース検査部、107・・品質評価部、108・・品質診断部、109・・能力診断部、110・・評価レポート、111・・データ格納部、112・・技術者情報、113・・コーディング経過情報、114・・診断情報、115・・ルール情報、116・・インスペクション結果情報、121・・開発マシン、122・・イントラネット、123・・管理端末、406・・「能力評価推移」欄、801・・ルールの重要度の一例、901・・ルールの種類の一例、1101・・品質評価基準の一例、1201・・能力評価推移および修正能力の表示の一例、1301・・プロジェクトに関する評価レポートの一例、1306・・推移グラフ、1307・・ルールごとの診断結果表示領域、1401・・ソースに関する評価レポートの一例、1403・・評価が悪いソースのトップ１０を示すグラフ、1404・・ソースごとの診断結果表示領域、1501・・技術者に関する評価レポートの一例、1503・・評価が悪い技術者のトップ１０を示すグラフ、1504・・技術者ごとの診断結果表示領域、1601・・会社に関する品質評価レポートの一例、1604・・会社ごとの診断結果表示領域、1701・・技術者に関する能力評価レポートの一例、1705・・技術者の能力評価推移の表示領域、1706・・評価ポイントの推移グラフ、1707・・ルールごとの診断結果表示領域、1801・・会社に関する能力評価レポートの一例、1805・・評価ポイントの推移グラフ、1806・・技術者ごとの診断結果表示領域、1901・・プロジェクトに関する品質推移レポートの一例、1904・・プロジェクトの品質推移結果表示領域、2001・・ソースに関する品質評価推移レポートの一例、2004・・ソースの品質推移結果表示領域、2101・・技術者に関する品質評価推移レポートの一例、2104・・技術者の品質推移結果表示領域、2201・・会社に関する品質推移レポートの一例、2204・・会社の品質推移結果推移領域、2901・・技術者、2902・・レビュアー、2904・・インスペクション結果レポート、2905・・プロジェクト管理者
【図１】
2006059276.tif 000003
【図２】
2006059276.tif 000004
【図３】
2006059276.tif 000005
【図４】
2006059276.tif 000006
【図５】
2006059276.tif 000007
【図６】
2006059276.tif 000008
【図７】
2006059276.tif 000009
【図８】
2006059276.tif 000010
【図９】
2006059276.tif 000011
【図１０】
2006059276.tif 000012
【図１１】
2006059276.tif 000013
【図１２】
2006059276.tif 000014
【図１３】
2006059276.tif 000015
【図１４】
2006059276.tif 000016
【図１５】
2006059276.tif 000017
【図１６】
2006059276.tif 000018
【図１７】
2006059276.tif 000019
【図１８】
2006059276.tif 000020
【図１９】
2006059276.tif 000021
【図２０】
2006059276.tif 000022
【図２１】
2006059276.tif 000023
【図２２】
2006059276.tif 000024
【図２３】
2006059276.tif 000025
【図２４】
2006059276.tif 000026
【図２５】
2006059276.tif 000027
【図２６】
2006059276.tif 000028
【図２７】
2006059276.tif 000029
【図２８】
2006059276.tif 000030
【図２９】
2006059276.tif 000031
【図３０】
2006059276.tif 000032
【図３１】
2006059276.tif 000033