(57)【要約】【課題】  本発明は、アプリケーションや各種のハードウエア装置に内蔵させるファームウエアなどのソフトウエアに発生するバグについて、バグ発見の報告から、原因追究、および解決に至るまでの追跡を行うバグ追跡システムに関する。【解決手段】  組織体の複数のブロックで使用する各バグ追跡システムを連携させ一括してバグ追跡を行うバグ管理サーバであって、あるブロックで発見された前記ソフトウエアのバグを関係する他ブロックへ関連付けてバグ管理リストに登録し、関連付けて登録された当該バグについて原因追究から修復に至るバグ追跡の状態を前記リストに記録し、関連付元となるブロックが、随時、バグ追跡の状態を含む前記バグ管理リストのバグ情報を参照することを特徴とするバグ管理サーバ。【選択図】図１
2006309316.tif 000002
【特許請求の範囲】
【請求項１】
組織体の複数のブロックで使用する各バグ追跡システムを連携させ一元化してバグ追跡を行うバグ管理サーバであって、
あるブロックで発見された前記ソフトウエアのバグを関係する他ブロックへ関連付けてバグ管理リストに登録する関連付登録手段と、
前記関連付登録手段で登録された当該バグについて原因追究から修復に至るバグ追跡の状態を前記バグ管理リストに記録する状態記録手段と、
前記関連付登録手段において関連付元となるブロックが、随時、バグ追跡の状態を含む前記バグ管理リストのバグ情報を参照する参照手段と、
を有することを特徴とするバグ管理サーバ。
【請求項２】
前記関連付登録手段において、あるブロックで発見されたバグを他ブロックへ関連付けて登録する際に、権限のある承認者の承認を得る設定とすることを特徴とする請求項１に記載のバグ管理サーバ。
【請求項３】
前記参照手段において、前記バグ管理リストのバグ追跡の状態が追究途中の段階にある場合、バグ原因を追究する当該ブロックによって、参照するバグ内容にフィルタリングが設定されることを特徴とする請求項１または２に記載のバグ管理サーバ。
【請求項４】
組織体の複数のブロックで使用する各バグ追跡システムを連携させ一元化してバグ追跡を行うバグ追跡方法であって、
あるブロックで発見された前記ソフトウエアのバグを関係する他ブロックへ関連付けてバグ管理リストに登録する関連付登録ステップと、
前記関連付登録ステップで登録された当該バグについて原因追究から修復に至るバグ追跡の状態を前記バグ管理リストに記録する状態記録ステップと、
前記関連付登録ステップにおいて関連付元となるブロックが、随時、バグ追跡の状態を含む前記バグ管理リストのバグ情報を参照する参照ステップと、
を有することを特徴とするバグ追跡方法。
【請求項５】
組織体の複数のブロックで使用する各バグ追跡システムを連携させ一元化してバグ追跡を行うバグ追跡プログラムであって、
コンピュータに、
あるブロックで発見された前記ソフトウエアのバグを関係する他ブロックへ関連付けてバグ管理リストに登録する関連付登録ステップと、
前記関連付登録ステップで登録された当該バグについて原因追究から修復に至るバグ追跡の状態を前記バグ管理リストに記録する状態記録ステップと、
前記関連付登録ステップにおいて関連付元となるブロックが、随時、バグ追跡の状態を含む前記バグ管理リストのバグ情報を参照する参照ステップと、
を実行させるバグ追跡プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションや各種のハードウエア装置に内蔵させるファームウエアなどのソフトウエアに発生するバグについて、バグ発見の報告から、原因追究、および解決に至るまでの追跡を行うバグ追跡システムに関する。
【背景技術】
【０００２】
最近、アプリケーション開発、システム開発、ハードウェア開発などの開発環境において、その開発規模はますますが増大する傾向にある。開発規模の増大に伴い、開発人員の増加や開発拠点の分散化が発生しており、バグやファイル修正などの発生情報を開発者全員が共有し、バグの解決状況やファイルの修正状況を追跡監視するシステムが必要となってきている。
【０００３】
こうしたソースファイルの変更や問題点などの情報を開発者全員が共有するシステムの例として、バグ追跡システム（ＢＴＳ：Bug Tracking System ）が挙げられる（例えば、非特許文献１）。
【０００４】
図１１に、従来のバグ追跡システムの構成例を示す。バグ追跡システム１００は、クライアント３００／サーバ２００で構成され、バグ登録、バグ追究状況の登録、バグ追究状況の参照、諸登録時の添付ファイル管理などを実現している。クライアント３００からの登録・参照要求によりサーバ２００にアクセスし、クライアント３００へ参照情報や登録情報の変更結果を報告する。また、バグ追跡システム１００は、バグについての情報だけでなく、バグに関連するファイルなども付加して管理することも可能としている。さらに、複数のクライアントが、同一のサーバ２００に対して上述の操作するための排他アクセス管理を行っている。
【非特許文献１】大福屋ホームページ、http://www.daifukuya.com/kagemai
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述のような構成によって実現される現状のバグ追跡システムは、組織体における単一の部門（以下、ブロックと表現）を対象としており、複数のブロックを対象としている場合には、以下に述べるような課題を抱える。
【０００６】
開発規模の拡大によるデータ量の増大や、開発拠点の分離化などにより、ブロック毎にそれぞれバグ追跡システム（ＢＴＳ）を運用するケースが発生しており、現状では、これら各ブロックのバグ追跡システム間での連携やデータのやり取りがなされておらず、バグ情報が共有されていないために、開発効率が極めて悪くなっている。
【０００７】
また、複数ブロックをまとめた一括管理では、関係情報を全て通知もしくは閲覧可能となり、開発者にとっては、不要な情報を受信する場合が多くなり、かえって不効率となる。必要な情報は通知もしくは閲覧可能とし、不必要な情報は遮蔽されるようなシステムの提供が望まれる。
【０００８】
さらに、複数ブロックで個別にバグ追跡システムを運用する環境下では、あるブロックで発見／報告されたバグが、他のブロックに起因する場合に、どのバグ追跡システムにてバグ原因の追究を行うかが問題となる。
【０００９】
例えば、組織体の複数の部門ブロックとして、図２に示すような顧客使用ブロック、製造・試験ブロック、開発ブロックを取り上げ、各ブロックが、同一製品に対して、それぞれ、ＢＴＳ１、ＢＴＳ２、およびＢＴＳ３のバグ追跡システムを介してバグ追跡を行っており、その内容が、別ブロックに関連し、情報の共有を必要とする場合を想定する。
【００１０】
そして、顧客使用ブロックにおいて、バグ登録が発生したとすると、その原因は、開発ブロックに有りとする場合、従来の単一ブロックで処理する方法では、１）顧客使用ブロックのバグ追跡システム上で、開発ブロックのメンバによるバグ原因追究を行うか、２）顧客使用ブロックのバグ追跡システムに登録されたバグを、開発ブロックのバグ追跡システムに再登録し直してバグの原因追究を行う方法が考えられる。
【００１１】
しかしながら、１）の方法では、顧客使用ブロックにおいて開発ブロックでのバグ追跡情報が共存することとなり、顧客使用ブロックにとっては不必要となる情報が見え、また、開発ブロックに秘密事項などが含まれた場合、該秘密情報がそのまま流出してしまう可能性がある。
【００１２】
また、2 ）の方法では、バグの登録を複数ブロックのバグ追跡システムに登録することになり、製品全体でのバグ登録件数の統計情報に正確さを失うこととなる。
【００１３】
さらに、開発ブロックのバグ追跡システムを使用したバグ原因追究の状況は、顧客使用ブロックからはブラックボックスであり、進捗が不透明である。
【００１４】
本発明は、バグ追跡システムにおける以上の課題を解決すべく、複数ブロックに関連するバグ追跡を高度に管理可能にすることを目的とするものである。
【課題を解決するための手段】
【００１５】
第一の発明は、組織体の複数のブロックで使用する各バグ追跡システムを連携させ一元化してバグ追跡を行うバグ管理サーバであって、あるブロックで発見された前記ソフトウエアのバグを関係する他ブロックへ関連付けてバグ管理リストに登録する関連付登録手段と、前記関連付登録手段で登録された当該バグについて原因追究から修復に至るバグ追跡の状態を前記バグ管理リストに記録する状態記録手段と、前記関連付登録手段において関連付元となるブロックが、随時、バグ追跡の状態を含む前記バグ管理リストのバグ情報を参照する参照手段と、を有することを特徴とするバグ管理サーバに関する。
【００１６】
すなわち、第一の発明によれば、関連付登録手段が、あるブロックで発見したバグを登録する場合に、バグ内容の分析から修復に至る一連のバグ追跡に関係する他ブロックを指定し、ブロック間を関連付けて指定先ブロックのバグ追跡システムに登録し、状態記録手段が、指定先ブロックにおいてバグの修復に至るバグ追跡の進捗状況を示す状態をバグ管理リストに記録し、参照手段によって、関連付元であるバグの発見元ブロックは、随時、このバグ管理リストを参照してバグ追究の進捗を把握できることとなる。
【００１７】
本発明によれば、複数ブロックに関連するバグを関連付けという手段で、複数ブロックのバグ追跡システムへ登録することにより、製品に対するバグ報告としては一件として分析できるバグ追跡システムを実現することができる。また、バグ発見したブロックからバグ原因を追究するブロックへ関連付けをたどることにより、バグ原因追究の詳細情報に関し、不必要な情報は省き、バグ原因追究の進捗状況等の必要な情報のみを参照することが可能となる。
【００１８】
第二の発明は、前記関連付登録手段において、あるブロックで発見されたバグを他ブロックへ関連付けて登録する際に、権限のある承認者の承認を得る設定とすることを特徴とする上記第一の発明に記載のバグ管理サーバに関する。
【００１９】
すなわち、第二の発明によれば、あるプロセスで発見されたバグを他のブロックへバグ登録する際には、しかるべき承認者による承認を得るよう設定可能にすることで、不必要な情報流出を抑制することができる。また、バグの修正完了（解決報告）をバグ原因追究のブロックからバグ発見のブロックへ登録する際にも、しかるべき承認者による承認を得るよう設定可能にすることで、不必要な情報流出や不完全なバグ修正完了の登録を抑制することができることとなる。
【００２０】
第三の発明は、前記参照手段において、前記バグ管理リストのバグ追跡の状態が追究途中の段階にある場合、バグ原因を追究する当該ブロックによって、参照するバグ内容にフィルタリングが設定されることを特徴とする上記第一または第二の発明に記載のバグ管理サーバに関する。
【００２１】
すなわち、第三の発明によれば、バグ発見のブロックからバグ原因追究のブロックへバグ原因追究状況を参照する際に、バグ原因追究のブロックが設定したフィルタリングを行うことで各ブロックが保有する機密事項の流出を抑制することが可能となる。
【発明の効果】
【００２２】
以上、上記してきた発明により以下の効果が生まれる。
１）複数ブロックに関連するバグを関連付けという手段で複数のバグ追跡システムへ登録することにより、製品に対するバグ報告としては一件として分析できるようなバグ追跡システムを実現することができる。また、バグ発見のブロックからバグ原因追究のブロックへの関連付けをたどることにより、バグ原因追究の詳細情報などの不必要な情報は省き、バグ原因追究の進捗状況などの必要な情報のみを参照することができる。
２）あるブロックで発見されたバグを他のブロックへバグ登録する際には、しかるべき承認者による承認を得るよう設定可能とすることによって、不必要な情報流出を抑制することができる。また、バグの修正完了をバグ原因追究のブロックからバグ発見のブロックへ登録する際にも、しかるべき承認者による承認を得るよう設定可能とすることによって、不必要な情報流出や不完全なバグ修正完了の登録を抑制することができる。
３）バグ発見のブロックからバグ原因追究のブロックへバグ原因追究の状況を参照する際に、バグ原因追究のブロックが設定したフィルタリングを行うことで、各ブロックが保有する機密事項の流出を抑制できる。
【発明を実施するための最良の形態】
【００２３】
以下、図面にもとづいて本発明の実施形態を説明する。
【００２４】
図１は、本発明の実施の形態になるバグ追跡システムの基本構成を示す。本バグ追跡システムは、ネットワーク４を介して互いに接続するバグ管理サーバ１と組織体の複数のブロック（部門）の使用端末であるクライアント３（３−１、３−２・・・３−ｎ）とで構成される。バグ管理サーバ１は、バグの追跡のために、ソフトウエアで発生したバグの登録から修正に至るまでの状況を追跡するバグ追跡プログラム１０およびバグ管理リスト２１を格納した記憶装置２を備える。
【００２５】
さらに、バグ追跡プログラム１０は、あるブロックでバグが発見されたときに、複数のブロックの中から関係するブロックを指定し、ブロック間を関連付けて登録する関連付登録手段１１、関連付したブロックでのバグの追究状況を記録する状態記録手段１２、発見元のブロックがバグの追究状況を参照する参照手段１３、バグ登録時に他ブロックへの関連付けを承認する承認手段１４、およびバグ参照時にバグ内容に開示したくない部分にフィルタリングをかけるフィルタリング手段１５で構成される。
【００２６】
なお、バグ管理サーバ１は、バグ追跡プログラム１０を内蔵するコンピュータであり、当該プログラムは、図示していないが、フレキシブルディスク、コンパクトディスク、ＲＯＭ（Read Only Memory）等のコンピュータ読み取り可能な記録媒体に記録され、内蔵あるいは外部接続された媒体読取装置にセットし、起動時にメモリにロードすることによって実行可能な状態としてもよい。
【００２７】
ここで、バグ追跡プログラム１０は、バグ管理サーバ１に内蔵する構成を示しているが、本発明はこれに限定されるものではなく、ネットワークに接続する装置の何処に配置されてもよい。
【００２８】
図２は、本発明の実施の形態になる複数ブロックにまたがるバグ追跡処理を表す模式図を示す。本模式図を使って、以下の１）〜４）のケースについて、複数のブロック間におけるバグの追跡の仕組みを説明する。
【００２９】
以下の実施例では、組織体の複数の部門ブロックとして、顧客使用ブロック、製造・試験ブロック、および開発ブロックの３つを取り上げ、各ブロックが、同一製品に対して、それぞれ、ＢＴＳ１、ＢＴＳ２、およびＢＴＳ３のバグ追跡システムを介してバグ追跡を行っており、その内容が、他ブロックに関連し、情報の共有を必要とする場合を想定して説明する。
【００３０】
なお、ＢＴＳ１、ＢＴＳ２、およびＢＴＳ３は、各々バグ情報を管理するバグ管理ファイル（図示していない）を備え、バグ管理サーバ１のバグ管理リスト２１は、各ＢＴＳと連携して当該バグ管理ファイルを一括管理するものである。
１）バグ登録時の関連付
顧客使用ブロック（部門）のバグ追跡システム（ＢＴＳ１）において、発見・登録されたバグが、開発ブロックのバグ追跡システム（ＢＴＳ３）に起因すると判明した場合に、顧客使用ブロックでのバグ登録と関連付けを持たせて、開発ブロックのバグ追跡システム（ＢＴＳ３）へのバグ登録を行う。
２）バグの参照
顧客使用ブロックにて発見・登録されたバグについて関連付け（バグ管理リスト２１内の関連付け情報）をたどることにより現在のバグの追究状況を参照することができる。
【００３１】
例えば、開発ブロックにおいてバグ原因追究を行っており、「状態」としてはバグ原因の判明である、というような状態情報が得られる。また、参照時には、「状態」の情報だけでなく必要であれば、開発ブロック側のバグ追跡システム（ＢＴＳ３）上に存在する全情報（現状までのバグ原因追究についての詳細情報・添付ファイル群など）を要求し、取得することも可能である。
【００３２】
さらに、開発ブロックのバグ追跡システム（ＢＴＳ３）に登録されている情報のうち顧客使用ブロック（ＢＴＳ１）から参照可能なデータとして、開発ブロック側において条件を設定し、フィルタリング処理することによって参照情報をコントロールすることができる。例えば、顧客使用ブロックからの参照に対して、開発ブロックにて原因判明ステータスの参照を許可せずフィルタリングを実行している場合には、一つ前のバグ受付までの情報が顧客使用ブロックから参照し得る情報となる。
３）バグ追跡完了
開発ブロック（バグ原因追究のブロック）でのバグ修正完了報告により、顧客使用ブロック（バグ発見・登録のブロック）にて完了判定し最終的な完了とする。顧客使用ブロックでの完了を開発ブロックについても反映し完了とすることによって、完了情報の併合を行うことができる。リストの動作としては、関連付けの情報を参照することで、両ブロックのＢＴＳの完了を同じタイミングで反映させることとなる。
４）承認制限
他ブロックへ同一バグを登録する際には、承認項目を設定しておき、承認が得られなかった場合には、関連付けバグ登録を抑止する。例えば、製造・試験ブロックから顧客使用ブロックへ関連付けさせたバグ登録の可否を承認制限している場合には、承認された場合にのみ登録を行うこととなる。
【００３３】
図３は、本発明の実施の形態になるバグ追跡システムにおけるバグ管理リストのデータ構成例を示す。バグ管理リスト２１において、複数のブロックの各バグ追跡システム内で作られ保管されるバグ情報ファイルが、一元的にサーバ側で管理される。
【００３４】
各ブロックで使用するバグ追跡システム個別の認識番号「ＢＴＳ  Ｎｏ」、及びＢＴＳ内の「管理Ｎｏ」毎に管理され、「登録日時」、「状態」、「 内容」、「登録者」、「原因」、「追加ファイル」、および「対象ファイル」の項目からなる複数のレコードで構成される。
【００３５】
「状態」には、バグ情報の現在の状況を示しており、新規→バグ受付→原因判明→修正完了→完了などの更新情報を記す。また、「内容」は、「プログラムストップ」などクライアントからの登録についてのバグ内容の詳細を示し、「登録者」は、各アクセスに対する登録者の氏名を示す。また、「原因」には、未定か、判明が記され、さらに、「追加ファイル」には、当該ファイルが存在すれば、そのファイル名が記され、「対象ファイル」は、バグの対象となっているプログラム等のファイル名が記される。
【００３６】
図４は、本発明の実施の形態になるブロック間の関連付けによるバグ管理リストのデータ構成例を示す。バグ管理リスト２１は、図３のリスト項目に「関連付け」の項目が追加された構成となる。当該関連付け項目は、登録時に自動的に記入されるもので、関連付先のＢＴＳにおいて関連付元のＢＴＳ情報が付加されるとともに、関連付元のＢＴＳにおいても関連付先のＢＴＳ情報が付加される。
【００３７】
実施例では、ＢＴＳ１からの関連付けによるＢＴＳ３へのバグ登録により、ＢＴＳ１からの関連付け情報ＢＴＳ００１−００１が、ＢＴＳ３におけるバグ情報として「関連付け」項目に自動的に付記され、保管される例を示している。一方、関連付け元（ＢＴＳ１）のリストにも対応する情報が自動的に付記される。関連付け先での関連付け情報としては、本例の場合、ＢＴＳ００３−００１となる。
【００３８】
なお、本実施例では、関連付けを持ったバグの再登録として示しているが、顧客使用ブロックからの分岐として実現することも可能である。
【００３９】
図５は、本発明の実施の形態になる承認制限時におけるバグ管理リストのデータ構成例を示す。バグ管理リスト２１は、図３のリスト項目に、例えば、プロジェクトリーダ等の「承認者」及び「承認」状態の項目が付加された構成となっている。
【００４０】
関連付け登録前の承認状態に対応させて、設定された「承認者」および「承認」完／未完の情報を付記する。また、バグの修正完了をバグ原因追究のブロックからバグ発見のブロックへ登録する場合にも、承認状態を設定し、承認が得られなかった場合にはバグの修正完了を抑止する。なお、実施例では、バグ管理リスト２１のバグ追跡「状態」は、「新規」、「承認依頼」、および「関連付け」と記され、「承認」項目が「完」となった時点で「関連付け」が行われることを示している。
【００４１】
図６は、本発明の実施の形態になるフィルタリング処理時のバグ管理リストのデータ構成例を示す。バグ管理リスト２１は、図３のリスト項目に、「フィルタ項目」が付加された構成となっている。
【００４２】
フィルタリング対象の状態に関するキーワードの情報を付記し、ＢＴＳは付記された情報に基づいてフィルタリングを実行する。フィルタ項目を設定しておき、参照時に可能とする情報を管理する。例えば、「登録状況」と設定された場合には、一つ前の「状態」を参照可能としている。なお、図６では、状態のみをフィルタリングしているが、バグ追跡システム上の全情報についてのフィルタリングが可能である。
【００４３】
つぎに、図７〜図１０を用いて、本発明のバグ追跡システムの動作フローを以下に説明する。
【００４４】
図７は、本発明の実施の形態になる複数ブロックにおけるバグ登録処理フローを示す。      
【００４５】
本実施例では、図２をもとに、例えば、顧客使用ブロックにおいてバグが発見され、当該ブロックで使用するバグ追跡システム（ＢＴＳ１）でバグ登録するとともに、原因は開発ブロックにあるとして、関係するブロックとして開発ブロックを指定してブロック間の関連付け行い、開発ブロックで使用するＢＴＳ３にバグ登録することを想定している。
【００４６】
ステップＳ１１：バグを発見した関連付元のブロックのバグ追跡システム（例えば、図２の顧客使用ブロックのＢＴＳ１）から関連付先のブロックのバグ追跡システム（例えば、図２の開発ブロックのＢＴＳ３）へバグ登録を要求する。
【００４７】
ステップＳ１２：バグ登録要求元（ＢＴＳ１）で関連付ブロックを決定し、登録するバグ情報をＢＴＳ１から取得する。
【００４８】
ステップＳ１３：関連付けを行う場合に、権限のある承認者の承認を必要としているかの承認制限の判定を行う。
【００４９】
ステップＳ１４：判定の結果、「承認」を必要とする場合には、承認者による承認が完了となった時点で、関係ブロックの関連付けを決定する。
【００５０】
ステップＳ１５：バグ発見ブロック（ＢＴＳ１）からバグ原因追究ブロック（ＢＴＳ３）へのバグ登録を通知する。
【００５１】
ステップＳ１６：関連付先（ＢＴＳ３）において、ＢＴＳ１から取得したバグ情報をバグ管理リスト２１に追加するとともに、関連付元（ＢＴＳ１）へフィードバックする関連付情報を決定する。
【００５２】
ステップＳ１７：バグ原因追究ブロック（ＢＴＳ３）からバグ発見ブロック（ＢＴＳ１）への関連付情報をフィードバックする。
【００５３】
ステップＳ１８：当該フィードバック情報をバグ管理リスト２１に保管して、本フローを終了する。
【００５４】
図８は、本発明の実施の形態になる複数ブロックにおけるバグ参照処理フローを示す。      
【００５５】
本実施例では、図７と同様、関連付元ブロックは顧客使用ブロック（ＢＴＳ１）、また、関連付先ブロックは開発ブロック（ＢＴＳ３）とし、ＢＴＳ１からＢＴＳ３のバグ追究状況を参照する場合について示す。
【００５６】
ステップＳ２１：関連付元（ＢＴＳ１）から関連付先（ＢＴＳ３）へバグの参照要求を行う。
【００５７】
ステップＳ２２：関連付元（ＢＴＳ１）が参照すべきバグの関連付先情報をバグ管理リスト２１から取得する。
【００５８】
ステップＳ２３：関連付元（ＢＴＳ１）から関連付先（ＢＴＳ３）へ当該バグの参照を通知する。
【００５９】
ステップＳ２４：関連付先（ＢＴＳ３）において、関連付情報を基にバグ管理リスト２１より参照要求のあったバグの追究情報を抽出し、関連付元（ＢＴＳ１）へのフィードバック用データとして決定する。また、フィルタリングを設定する際には、バグ管理リスト２１のフィルタリング情報を参照して決定する。
【００６０】
ステップＳ２５：関連付先（ＢＴＳ３）から関連付元（ＢＴＳ１）へバグの追究状況の情報をフィードバックする。
【００６１】
ステップＳ２６：関連付先元ブロック（ＢＴＳ１）の使用者へフィードバックデータを通知して本フローを終了する。
【００６２】
図９は、本発明の実施の形態になる複数ブロックにおけるバグ追跡完了処理フロー（ａ：バグ修正完了通知）を示す。
【００６３】
本実施例においても、図７と同様、関連付元ブロックは顧客使用ブロック（ＢＴＳ１）、また、関連付先ブロックは開発ブロック（ＢＴＳ３）とした場合のバグ追跡完了について示す。
【００６４】
ステップＳ３１：関連付先（ＢＴＳ３）において、バグ修正完了の報告を行う。
【００６５】
ステップＳ３２：関連付先（ＢＴＳ３）のバグ管理リスト２１から修正完了したバグの関連付元情報を取得する。
【００６６】
ステップＳ３４：関連付元（ＢＴＳ１）において、修正完了通知のあったバグについて関連付情報を基にバグ管理リスト２１へ修正完了情報を反映させる。
【００６７】
ステップＳ３５：関連付元ブロック（ＢＴＳ１）の使用者へのバグ修正完了の通知を行い、図１０のフローｂに進む。
【００６８】
図１０は、本発明の実施の形態になる複数ブロックにおけるバグ追跡完了処理フロー（ｂ：バグ追跡完了報告）を示す。
【００６９】
ステップＳ４１：図９のバグ追跡完了処理フロー（ａ）を受けて、関連付元ブロック（ＢＴＳ１）の使用者によるバグ修正の確認、追跡完了の報告を行う。
【００７０】
ステップＳ４２：関連付元（ＢＴＳ１）において、追跡完了報告のあったバグについてバグ管理リスト２１への完了報告と関連付先情報を取得する。
【００７１】
ステップＳ４３：関連付元（ＢＴＳ１）から関連付先（ＢＴＳ３）へのバグ追跡完了の通知を行う。
【００７２】
ステップＳ４４：関連付先（ＢＴＳ３）において、関連付情報を基に、追跡完了通知のあったバグについてバグ管理リスト２１へ追跡完了情報を反映させる。
【００７３】
ステップＳ４５：関連付先ブロック（ＢＴＳ３）の使用者へバグ追跡完了を通知して、本フローを終了する。
【００７４】
以上述べてきた本発明の実施の態様は、以下の付記に示す通りである。
（付記１）  組織体の複数のブロックで使用する各バグ追跡システムを連携させ一元化してバグ追跡を行うバグ管理サーバであって、
あるブロックで発見された前記ソフトウエアのバグを関係する他ブロックへ関連付けてバグ管理リストに登録する関連付登録手段と、
前記関連付登録手段で登録された当該バグについて原因追究から修復に至るバグ追跡の状態を前記バグ管理リストに記録する状態記録手段と、
前記関連付登録手段において関連付元となるブロックが、随時、バグ追跡の状態を含む前記バグ管理リストのバグ情報を参照する参照手段と、
を有することを特徴とするバグ管理サーバ。
（付記２）  前記関連付登録手段において、あるブロックで発見されたバグを他ブロックへ関連付けて登録する際に、権限のある承認者の承認を得る設定とすることを特徴とする付記１に記載のバグ管理サーバ。
（付記３）  前記参照手段において、前記バグ管理リストのバグ追跡の状態が追究途中の段階にある場合、バグ原因を追究する当該ブロックによって、参照するバグ内容にフィルタリングが設定されることを特徴とする付記１または２に記載のバグ管理サーバ。
（付記４）  前記複数ブロックからなるバグ追跡において、あるブロックで解決したバグについて、他のブロックのバグ追跡システムと併合させてバグの追跡を一括管理することを特徴とする付記１に記載のバグ管理サーバ。
（付記５）  前記複数ブロックからなるバグ追跡において、関連付けまたは参照されたバグの件数を統計情報として収集することを特徴とする付記１乃至４のいずれかに記載のバグ管理サーバ。
（付記６）  組織体の複数のブロックで使用する各バグ追跡システムを連携させ一元化してバグ追跡を行うバグ追跡方法であって、
あるブロックで発見された前記ソフトウエアのバグを関係する他ブロックへ関連付けてバグ管理リストに登録する関連付登録ステップと、
前記関連付登録ステップで登録された当該バグについて原因追究から修復に至るバグ追跡の状態を前記バグ管理リストに記録する状態記録ステップと、
前記関連付登録ステップにおいて関連付元となるブロックが、随時、バグ追跡の状態を含む前記バグ管理リストのバグ情報を参照する参照ステップと、
を有することを特徴とするバグ追跡方法。
（付記７）  組織体の複数のブロックで使用する各バグ追跡システムを連携させ一元化してバグ追跡を行うバグ追跡プログラムであって、
コンピュータに、
あるブロックで発見された前記ソフトウエアのバグを関係する他ブロックへ関連付けてバグ管理リストに登録する関連付登録ステップと、
前記関連付登録ステップで登録された当該バグについて原因追究から修復に至るバグ追跡の状態を前記バグ管理リストに記録する状態記録ステップと、
前記関連付登録ステップにおいて関連付元となるブロックが、随時、バグ追跡の状態を含む前記バグ管理リストのバグ情報を参照する参照ステップと、
を実行させるバグ追跡プログラム。
【図面の簡単な説明】
【００７５】
【図１】本発明の実施の形態になるバグ追跡システムの基本構成を示す図である。
【図２】本発明の実施の形態になる複数ブロックにまたがるバグ追跡処理を表す模式図である。
【図３】本発明の実施の形態になるバグ追跡システムにおけるバグ管理リストのデータ構成例を示す図である。
【図４】本発明の実施の形態になるブロック間の関連付けによるバグ管理リストのデータ構成例を示す図である。
【図５】本発明の実施の形態になる承認制限時におけるバグ管理リストのデータ構成例を示す図である。
【図６】本発明の実施の形態になるフィルタリング処理時のバグ管理リストのデータ構成例を示す図である。
【図７】本発明の実施の形態になる複数ブロックにおけるバグ登録処理フローを示す図である。
【図８】本発明の実施の形態になる複数ブロックにおけるバグ参照処理フローを示す図である。
【図９】本発明の実施の形態になる複数ブロックにおけるバグ追跡完了処理フロー（ａ：バグ修正完了通知）を示す図である。
【図１０】本発明の実施の形態になる複数ブロックにおけるバグ追跡完了処理フロー（ｂ：バグ追跡完了報告）を示す図である。
【図１１】従来の各ブロック毎のバグ追跡システムの構成を示す図である。
【符号の説明】
【００７６】
１  バグ管理サーバ
２  記憶装置
３  クライアント
４  ネットワーク
１０  バグ追跡プログラム
１１  関連付登録手段
１２  状態記録手段
１３  参照手段
１４  承認手段
１５  フィルタリング手段
【図１】
2006309316.tif 000003
【図２】
2006309316.tif 000004
【図３】
2006309316.tif 000005
【図４】
2006309316.tif 000006
【図５】
2006309316.tif 000007
【図６】
2006309316.tif 000008
【図７】
2006309316.tif 000009
【図８】
2006309316.tif 000010
【図９】
2006309316.tif 000011
【図１０】
2006309316.tif 000012
【図１１】
2006309316.tif 000013