JP2010165082A - 開発管理情報収集システム - Google Patents

Abstract

【課題】管理対象の規模が拡大しても高速な処理が可能で、ソースコードに対する追加、削除、修正の事実を集計可能な技術の提供。
【解決手段】外部のソース格納部32に格納されている各ソースファイルのレプリカ42を格納しておく内部ファイル格納部16と、定期的にソース格納部32から変更済のソースファイルを取得して内部ファイル格納部16の一時保存領域44にコピーするソース取得部12と、レプリカ42上のソースファイルと更新済のソースファイルとを比較し、ソースコードの削除行数、追加行数、修正行数を計数し、その計数結果を各ソースファイルに関連付けて実績管理ＤＢ22に格納すると共に、変更済のソースファイルによってレプリカ42を更新する解析処理部20を備えた開発管理情報収集システム10。
【選択図】図１

Description

この発明は開発管理情報収集システムに係り、特に、システム開発の進捗状況等を管理するための情報を自動収集する技術に関する。

システム開発を業とする企業においては、社内外において同時並行的に多数の開発プロジェクトが進行しているため、品質管理目標および生産性目標を最初に立てて、実績と目標値を比較することにより、各プロジェクトの進捗状況を常時把握し、開発計画に対する必要な修正をタイムリーに実施したり、各チームや技術者個人の効率性を評価したりすることが、管理者にとって極めて重要な職務となる。
このため、これまでもプログラム開発の進捗管理を目的とするツールや、プログラム開発の生産性を評価する技術が数多く提案されている（非特許文献１及び特許文献１を参照）。
ProjectKeeper ProfessionalインターネットURL：http://www.sios.com/product/projectkeeperpro/index.html?gclid=CLanyvj0xpcCFdUupAodNwqxSA検索日：平成２０年１２月１０日 特開平６−８３６０９

従来のプロジェクト管理ツールを用いることにより、ガントチャートを作成するなど、開発工程を可視化することは可能であるが、進捗データの入力はプログラマ本人あるいはマネジャが日々の業務の合間を縫って個別に行う必要があり、非常に手間暇がかかっていた。

これに対し、特許文献１においては、ソースプログラムファイルやオブジェクトプログラムファイルからファイルデータを取り出し、ライブラリ管理データベースの管理データを参照しながらソースステップ数及びオブジェクトファイルサイズを自動的に算出し、ソフトウェア開発の生産性を求める技術が開示されている。この技術を応用することにより、プログラマやマネジャは、少なくともソースコードのステップ数をカウントする作業から解放されることとなる。

しかしながら、特許文献１の技術では、ソースプログラムファイルから管理対象となる全ファイルデータを読み込むことが前提となるため、管理対象の規模が拡大するにつれて処理時間が長くなるという問題があった。
また、特許文献１の場合、単純にソースコードのステップ数をカウントすることによって生産性を把握しようとするものであるが、追加されたステップ数、削除されたステップ数、修正されたステップ数を個別にカウントしなければ、真の意味でコーディング作業の生産性を評価することはできないといえる。
また、システム開発においては、ソースコードの作成以外の作業、例えば設計書の作成、マニュアルの作成といったドキュメント類の作成も重要な作業といえるのであるが、特許文献１の技術を含め、これまでドキュメント類の作成状況を自動的にカウントする技術は存在していなかった。
さらに、システム開発においては生産性の管理の他に、成果物の品質を管理することも重要な課題となる筈であるが、品質管理指標となるデータを自動的に集計する技術も存在していなかった。

この発明は、このような従来の課題を解決するために案出されたものであり、管理対象の規模が拡大しても高速な処理が可能であり、ソースコードに対する追加、削除、修正の事実を個別に集計可能な技術の提供を目的としている。また、ソースコード以外のドキュメント類に対する生産性の管理が可能な技術の提供、さらには、品質管理指標となるデータの自動集計が可能な技術の提供をも目的としている。

上記の目的を達成するため、請求項１に記載した開発管理情報収集システムは、外部のソースファイル記憶手段に格納されている各ソースファイルのレプリカを格納しておく記憶手段と、所定のタイミング（例えば１日１回）で上記ソースファイル記憶手段を参照し、変更済のソースファイルが存在している場合には、これを取得して所定の記憶手段に格納する手段と、上記レプリカ上に対応のソースファイルが存在する場合には、このレプリカ上のソースファイルと上記変更済のソースファイルとを比較し、少なくともソースコードの削除数量、追加数量、修正数量を計数する手段と、上記レプリカ上に対応のソースファイルが存在しない場合には、上記変更済のソースファイルに含まれるソースコードの全数量を追加数量として計数する手段と、上記計数結果を各ソースファイルに関連付けて所定の記憶手段に格納する手段と、変更済のソースファイルによって上記レプリカを更新する手段を備えたことを特徴としている。
上記「数量」としては、例えば、コメント行を含めたソースコードの行数、あるいはコメント行を除いたソースコードの行数（ステップ数）が該当する。

請求項２に記載した開発管理情報収集システムは、請求項１のシステムであって、さらに、外部の文書ファイル記憶手段に格納されている各文書ファイルのレプリカを格納しておく記憶手段と、所定のタイミングで上記文書ファイル記憶手段を参照し、変更済の文書ファイルが存在している場合には、これを取得して所定の記憶手段に格納する手段と、上記レプリカ上に対応の文書ファイルが存在する場合には、このレプリカ上の文書ファイルと上記変更済の文書ファイルとを比較し、少なくとも文書内容の削除数量、追加数量、修正数量を計数する手段と、上記レプリカ上に対応の文書ファイルが存在しない場合には、上記変更済の文書ファイルに含まれる文書内容の全数量を追加数量として計数する手段と、上記計数結果を各文書ファイルに関連付けて所定の記憶手段に格納する手段と、変更済の文書ファイルによって上記レプリカを更新する手段を備えたことを特徴としている。
上記「数量」としては、例えば、各文書の行数やページ数が該当する。

請求項３に記載した開発管理情報収集システムは、請求項１または２のシステムであって、さらに、各ソースファイルに対する品質管理指標データを、外部の品質管理データ記憶手段から取得する手段と、上記品質管理指標データの件数を、ソースファイル毎に集計する手段と、上記ソースファイルのレプリカを参照し、各ソースファイルに含まれるソースコードの数量を算出する手段と、各ソースファイルの品質管理指標データの件数及びソースコードの数量に基づいて、ソースファイル毎の品質管理指標密度を算出する手段と、上記算出結果を各ソースファイルに関連付けて所定の記憶手段に格納する手段を備えたことを特徴としている。
上記「品質管理指標データ」としては、例えば、レビュアによって指摘された問題点を記録した指摘事項データや、単体テストの結果生じた障害（バグ）を記録した障害事項データが該当する。

請求項１に記載した開発管理情報収集システムにあっては、内部にソースファイル記憶手段のレプリカを備えており、変更済のソースファイルのみを所定のタイミングで外部のソースファイル記憶手段から取得する差分取得方式を採用しているため、変更のなされていないファイルを含めた全ファイルを取り込む従来の方式に比較して、全体の処理速度を大幅に短縮させることができる。
また、単純に各ソースファイルのステップ数をカウントするのではなく、前回更新時のソースファイルと変更済のソースファイルを比較し、削除数量、追加数量、修正数量をカウントする機能を備えているため、プログラマの作業量を正確に把握することが可能となる。

請求項２に記載した開発管理情報収集システムにあっては、文書ファイルの内容に対する追加数量、修正数量、削除数量をカウントする機能を備えているため、設計書やマニュアルといったドキュメント類の作成状況を正確に把握することが可能となる。

請求項３に記載した開発管理情報収集システムにあっては、ソースファイル毎に品質管理指標データの件数や密度を算出する機能を備えているため、成果物の品質を管理することが可能となる。

図１は、この発明に係る開発管理情報収集システム10の全体構成を示すブロック図であり、ソース取得部12と、文書取得部14と、内部ファイル格納部16と、品質管理データ取得部18と、解析処理部20と、実績管理ＤＢ22とを備えている。
ソース取得部12、文書取得部14、品質管理データ取得部18及び解析処理部20は、コンピュータのCPUが、OS及び専用のアプリケーションプログラムに従って動作することにより、実現される。
また、内部ファイル格納部16及び実績管理ＤＢ22は、同コンピュータのハードディスク内に設けられている。

ソース取得部12には、通信ネットワークを介して、外部のソース管理サーバ30が接続されている。
ソース管理サーバ30は、多数のプロジェクトに係るソースファイルのバージョン管理機能を備えており、ソース格納部32には管理対象となる全ソースファイルが格納されている。

すなわち、ソース格納部32内にはプロジェクト毎に専用のフォルダが設けられている。また、各プロジェクトのフォルダ内にはバージョン毎に別フォルダが設けられており、その中には複数のソースファイルが格納されている。

図２(b)はソース格納部32の内部構造を例示する模式図であり、あるプロジェクト（PJ-001A）のフォルダ内にVer.1.01とVer.1.02の各バージョンに対応したフォルダが設けられており、Ver.1.02のフォルダ内にはファイルＡ〜Ｅ…が格納されている様子が描かれている。

図２(a)に示すように、システム10の内部ファイル格納部16には、ソース取得部12によってソース格納部32のレプリカ（複製）42が生成されている。このレプリカ42は、ソース取得部12によって定期的に差分更新されるのであるが、詳細は後述する。

文書取得部14には、通信ネットワークを介して、外部の文書管理サーバ34が接続されている。
文書管理サーバ34は、多数のプロジェクトに係る各種文書ファイル（拡張子がtxt, doc, xls, pdf等のファイル）のバージョン管理機能を備えており、文書格納部36には管理対象となる全ドキュメントファイルが格納されている。

すなわち、図示は省略するが、文書格納部36内にはプロジェクト毎に専用のフォルダが設けられている。また、各プロジェクトのフォルダ内にはバージョン毎に別フォルダが設けられており、その中には複数の文書ファイルが格納されている。

内部ファイル格納部16には、文書取得部14によって文書格納部36のレプリカ（複製）が生成されている（図示省略）。このレプリカも、文書取得部14によって定期的に差分更新されるのであるが、詳細は後述する。

品質管理データ取得部18には、通信ネットワークを介して、外部の品質管理サーバ38が接続されている。品質管理サーバ38は、多数のプロジェクトに係る品質管理データを格納しておく品質管理データ格納部40を備えている。
ここで品質管理データとしては、例えば以下のものが該当する。

［指摘事項データ］
これは、所定の経験を積んだ技術者であるレビュアがソースコードを目視でチェックし、その結果指摘された問題点を記録しておくためのデータベースであり、図３に示すように、指摘No、日付、プロジェクトID、バージョン、対象ファイル、指摘者、指摘箇所、指摘内容等のデータ項目を備えたレコードが格納されている。

［障害事項データ］
これは、ソースコードをコンパイルして単体テストを行った結果、障害（バグ）が発生した事実を記録しておくためのデータベースであり、図４に示すように、障害No、日付、プロジェクトID、バージョン、対象ファイル、テスト担当者、障害内容、原因等のデータ項目を備えたレコードが格納されている。

つぎに、図５のフローチャートに従い、ソースファイルに対する収集・解析処理について説明する。
まずソース取得部12は、ソース格納部32内の構成と内部ファイル格納部16に設けられたレプリカ42内の構成とを比較し、前回収集時にソース格納部32内に存在したソースファイルが現時点で存在しない場合には、当該ソースファイル自体が削除されたものと認定し、内部ファイル格納部16内に形成されたレプリカ42から該当のファイルを削除する（Ｓ10）。

図２の例で説明すると、ソース格納部32のVer.1.02のフォルダ内に前回収集時（2008年10月24日）に存在していたファイルＢが、現時点（2008年10月25日）では存在しないため、ソース取得部12はレプリカ42上の対応ファイルを削除する。

つぎにソース取得部12は、ソース格納部32の各フォルダ内に格納されたソースファイルの更新日をチェックし、前回収集時以降の更新日が刻印されているファイルを「変更あり」と認定し、これら前回の収集時以降に変更のあったソースファイルをソース格納部32から取得した後、内部ファイル格納部16の一時保存領域44にコピーする（Ｓ12）。
ここで「変更あり」に該当するパターンとしては、前回もソースファイル自体は存在したが、内容に修正が加えられた場合と、前回存在しなかったソースファイルが新規作成された場合がある。

図２の例では、ファイルＤ及びファイルＥの更新日が共に2008年10月25日であり、前回の収集日である2008年10月24日以降の日付に該当するため、ファイルＤ及びファイルＥが一時保存領域44にコピーされる。因みに、ファイルＥはレプリカ42上に存在していないため、新規作成ファイルに該当する。
これに対し、ファイルＡの更新日は2008年10月21日であり、ファイルＣの更新日は2008年10月23日であるため、ソース取得部12は「変更なし」と認定し、ファイルＡ及びＣのコピーは行わない。
なお、新しいバージョンのフォルダが新設されていた場合には、その中に含まれる全ファイルが「新規作成」に該当するため、一時保存領域44にフォルダごとコピーされる。

この実施の形態においては、ソース取得部12が１日１回、定時にバッチ処理によって変更済ソースファイルの収集を実行することが前提となっているため、上記のように日付によって変更の有無を判断しているが、不定期に変更済ソースファイルの収集を実行する場合には、各ソースファイルの更新日時に基づいて変更の有無を判断すればよい。

つぎに解析処理部20が起動し、内部ファイル格納部16の一時保存領域44に格納された変更済ソースファイルから、以下のデータを抽出する（Ｓ14）。
(1) 変更後のソースファイルの総行数
(2) 変更後のソースファイルの総ステップ数（総行数からコメント行の行数を減じた値）
(3) 変更後のソースファイル中の分岐数（if文、for文、switch文等の数）

つぎに解析処理部20は、内部ファイル格納部16の一時保存領域44に格納された変更済ソースファイルの内容と、レプリカ42内の対応ソースファイルの内容とを比較し、変更点を抽出する（Ｓ16）。具体的には、以下のデータが抽出される。
(1) 削除行数・・・前回のソースファイル中に存在したソースコードの中で、今回のソースファイル中に存在しないソースコードの行数
(2) 追加行数・・・今回のソースファイル中に存在するソースコードの中で、前回のソースファイル中に存在しないソースコードの行数
(3) 修正行数・・・前回及び今回のソースファイル中に存在するが、その記述内容に変更がなされているソースコードの行数
なお、変更済ソースファイルが「新規作成」に該当する場合、ソースコードの全行数が追加行数としてカウントされる。
「行数」の代わりに、ソースコードからコメント行を除いた「ステップ数」をカウントの単位として採用し、「削除ステップ数」、「追加ステップ数」、「修正ステップ数」を求めるようにすることもできる。

解析処理部20は、上記の各データを、ソースファイルの識別情報に関連付けて実績管理ＤＢ22に格納する（Ｓ18）。
図６は、その登録例を示す図表であり、各レコードは日付、プロジェクトID、バージョン、ファイル名、追加行数、修正行数、削除行数、総行数、総ステップ数、分岐数のデータ項目を備えている。これらの中、プロジェクトID、バージョン及びファイル名が、ソースファイルの識別情報に該当する。

つぎに解析処理部20は、今回変更があるものと認定されたソースファイルによって、内部ファイル格納部16内に形成されたレプリカ42に対し、必要な更新処理を施す（Ｓ20）。例えば、図２のケースでいえば、一時保存領域44のファイルＤによってレプリカ42上のファイルＤが上書されると共に、一時保存領域44のファイルＥがレプリカ42上に追加される。
この結果、内部ファイル格納部16内のレプリカが最新の状態に更新される。

つぎに、図７のフローチャートに従い、文書ファイルに対する収集・解析処理について説明する。
まず文書取得部14は、文書格納部36内の構成と内部ファイル格納部16に設けられた文書格納部のレプリカ内の構成とを比較し、前回収集時に文書格納部36内に存在した文書ファイルが現時点で存在しない場合には、当該文書ファイル自体が削除されたものと認定し、内部ファイル格納部16内に形成されたレプリカから該当の文書ファイルを削除する（Ｓ30）。

つぎに文書取得部14は、文書格納部36内のディレクトリ構造及び各文書ファイルの更新日をチェックし、前回収集時以降の更新日が刻印されているファイルを「変更あり」と認定し、これら前回の収集時以降に変更のあった文書ファイルを文書格納部36から取得した後、内部ファイル格納部16の一時保存領域44にコピーする（Ｓ32）。
ここで「変更あり」に該当するパターンとしては、前回も文書ファイル自体は存在したが、内容に修正が加えられた場合と、前回存在しなかった文書ファイルが新規作成された場合がある。

つぎに解析処理部20が起動し、内部ファイル格納部16の一時保存領域に格納された変更済文書ファイルから、以下のデータを抽出する（Ｓ34）。
(1) 変更後の文書ファイルの総行数
(2) 変更後の文書ファイルの総ページ数

つぎに解析処理部20は、内部ファイル格納部16の一時保存領域に格納された変更済文書ファイルの内容と、レプリカ内の対応文書ファイルの内容とを比較し、変更点を抽出する（Ｓ36）。具体的には、以下のデータが抽出される。
(1) 削除行数・・・前回の文書ファイル中に存在した行の中で、今回の文書ファイル中に存在しない行の数
(2) 追加行数・・・今回の文書ファイル中に存在する行の中で、前回のソースファイル中に存在しない行の数
(3) 修正行数・・・前回及び今回の文書ファイル中に存在するが、その記述内容に変更がなされている行の数
「行数」の代わりに「ページ数」をカウントの単位として採用し、「削除ページ数」、「追加ページ数」、「修正ページ数」を求めるようにすることもできる。

解析処理部20は、上記の各データを、文書ファイルの識別情報（プロジェクトID、バージョン及びファイル名）に関連付けて実績管理ＤＢ22に格納する（Ｓ38）。

つぎに解析処理部20は、今回変更があるものと認定された文書ファイルによって、内部ファイル格納部16内に形成されたレプリカに対して必要な更新処理を施す（Ｓ40）。この結果、内部ファイル格納部16内のレプリカが最新の状態に更新される。

つぎに、図８のフローチャートに従い、指摘事項データの収集・解析処理について説明する。
まず品質管理データ取得部18は、品質管理データ格納部40から最新の指摘事項データファイルを取得し、内部ファイル格納部16の一時保存領域44にコピーする（Ｓ50）。
つぎに、解析処理部20が起動し、ソースファイル毎に指摘事項の件数を集計する（Ｓ52）。

つぎに、解析処理部20は内部ファイル格納部16に設けられたソース格納部のレプリカ42を参照し、各ソースファイルの行数を取得する（Ｓ54）。
つぎに、解析処理部20は各ソースファイルの指摘事項の件数及びソースファイルの行数を以下の式に代入することにより、ソースコード1000行当たりの指摘数、すなわち「指摘密度」を算出する（Ｓ56）。
（１０００／ソースファイルの行数）×指摘件数
なお、「1000行当たり」は一例であり、他の数値を適用した指摘密度を求めることも当然に可能である。

解析処理部20は、上記の指摘密度及び指摘数の各データを、実績管理ＤＢ22に格納する（Ｓ58）。
図９は、その登録例を示す図表であり、各レコードは日付、プロジェクトID、バージョン、指摘対象のファイル名、指摘件数、指摘密度のデータ項目を備えている。

つぎに、図１０のフローチャートに従い、障害事項データの収集・解析処理について説明する。
まず品質管理データ取得部18は、品質管理データ格納部40から最新の障害事項データファイルを取得し、内部ファイル格納部16の一時保存領域44にコピーする（Ｓ60）。
つぎに、解析処理部20が起動し、ソースファイル毎に障害事項の件数を集計する（Ｓ62）。

つぎに、解析処理部20は内部ファイル格納部16に設けられたソース格納部のレプリカ42を参照し、各ソースファイルの行数を取得する（Ｓ64）。
つぎに、解析処理部20は各ソースファイルの障害事項の件数及びソースファイルの行数を以下の式に代入することにより、ソースコード1000行当たりの障害数、すなわち「障害密度」を算出する（Ｓ66）。
（１０００／ソースファイルの行数）×障害件数
この場合も、「1000行当たり」は一例であり、他の数値を適用した障害密度を求めることもできる。

解析処理部20は、上記の障害密度及び障害数の各データを、実績管理ＤＢ22に格納する（Ｓ68）。
図１１は、その登録例を示す図表であり、各レコードは日付、プロジェクトID、バージョン、テスト対象のファイル名、障害件数、障害密度のデータ項目を備えている。

プロジェクトマネジャは、クライアント端末50を操作することにより、実績管理ＤＢ22に格納された各種の解析結果データを様々な用途に利用することができる。
例えば、ソースファイル毎の追加行数、修正行数、削除行数を日ごとにプロットしたグラフを、EXCEL（登録商標）等のグラフ作成機能を備えたプログラムを用いて生成し、ディスプレイに表示させることにより、コーディング作業が計画通りに進んでいるか否かを一目で確認することが可能となる。
また、各ソースファイルと担当プログラマとを関連付けたデータをリンクさせることにより、プログラマ毎の日々の開発進度や成果を把握することも可能となる。

実績管理ＤＢ22には、文書ファイルに係る追加行数、修正行数、削除行数等のデータも蓄積されているため、プロジェクトマネジャはソースコードの作成作業と並行して、マニュアル作成等の進捗状況を把握することも可能となる。

さらに、実績管理ＤＢ22には、各ソースファイルに対するレビュアの指摘件数や指摘密度、障害発生件数、障害発生密度といった品質管理データも格納されているため、プロジェクトマネジャは生産性の管理のみならず、品質の管理をも併せて行うことが可能となる。

上記のように、ソース取得部12及び文書取得部14は、それぞれ外部のソース格納部32及び文書格納部36から変更のあった差分ファイルのみを取り込む機能を備えているため、変更のなされていないファイルを含めた全ファイルを取り込む場合に比較して、全体の処理速度を大幅に短縮させることが可能となる。

この発明に係る開発管理情報収集システムの全体構成を示すブロック図である。 ソース格納部と内部ファイル格納部との間におけるファイルのコピーや更新等を示す説明図である。 指摘事項データの構成例を示す図である。 障害事項データの構成例を示す図である。 ソースファイルに対する収集・解析処理の手順を示すフローチャートである。 ソースファイルに対する解析結果の登録例を示す図である。 文書ファイルに対する収集・解析処理の手順を示すフローチャートである。 指摘事項データに対する収集・解析処理の手順を示すフローチャートである。 指摘事項データに対する解析結果の登録例を示す図である。 障害事項データに対する収集・解析処理の手順を示すフローチャートである。 障害事項データに対する解析結果の登録例を示す図である。

10 開発管理情報収集システム
12 ソース取得部
14 文書取得部
16 内部ファイル格納部
18 品質管理データ取得部
20 解析処理部
22 実績管理ＤＢ
30 ソース管理サーバ
32 ソース格納部
34 文書管理サーバ
36 文書格納部
38 品質管理サーバ
40 品質管理データ格納部
42 ソース格納部のレプリカ
44 一時保存領域
50 クライアント端末

Claims (3)

1. 外部のソースファイル記憶手段に格納されている各ソースファイルのレプリカを格納しておく記憶手段と、
   所定のタイミングで上記ソースファイル記憶手段を参照し、変更済のソースファイルが存在している場合には、これを取得して所定の記憶手段に格納する手段と、
   上記レプリカ上に対応のソースファイルが存在する場合には、このレプリカ上のソースファイルと上記変更済のソースファイルとを比較し、少なくともソースコードの削除数量、追加数量、修正数量を計数する手段と、
   上記レプリカ上に対応のソースファイルが存在しない場合には、上記変更済のソースファイルに含まれるソースコードの全数量を追加数量として計数する手段と、
   上記計数結果を各ソースファイルに関連付けて所定の記憶手段に格納する手段と、
   変更済のソースファイルによって上記レプリカを更新する手段と、
   を備えたことを特徴とする開発管理情報収集システム。
2. 請求項１に記載の開発管理情報収集システムであって、さらに、
   外部の文書ファイル記憶手段に格納されている各文書ファイルのレプリカを格納しておく記憶手段と、
   所定のタイミングで上記文書ファイル記憶手段を参照し、変更済の文書ファイルが存在している場合には、これを取得して所定の記憶手段に格納する手段と、
   上記レプリカ上に対応の文書ファイルが存在する場合には、このレプリカ上の文書ファイルと上記変更済の文書ファイルとを比較し、少なくとも文書内容の削除数量、追加数量、修正数量を計数する手段と、
   上記レプリカ上に対応の文書ファイルが存在しない場合には、上記変更済の文書ファイルに含まれる文書内容の全数量を追加数量として計数する手段と、
   上記計数結果を各文書ファイルに関連付けて所定の記憶手段に格納する手段と、
   変更済の文書ファイルによって上記レプリカを更新する手段と、
   を備えたことを特徴とする開発管理情報収集システム。
3. 各ソースファイルに対する品質管理指標データを、外部の品質管理データ記憶手段から取得する手段と、
   上記品質管理指標データの件数を、ソースファイル毎に集計する手段と、
   上記ソースファイルのレプリカを参照し、各ソースファイルに含まれるソースコードの数量を算出する手段と、
   各ソースファイルの品質管理指標データの件数及びソースコードの数量に基づいて、ソースファイル毎の品質管理指標密度を算出する手段と、
   上記算出結果を各ソースファイルに関連付けて所定の記憶手段に格納する手段と、
   を備えたことを特徴とする請求項１または２に記載の開発管理情報収集システム。

Images