(57)【要約】【課題】  ソフトウェア開発プロジェクトにおいて優先して取り組むべきバグに対して類似するバグを選定し対策修正することを支援することにより、特にデバッグにかかわるソフトウェア開発工数を改善する方法が必要である。【解決手段】  バグの重要度や修正進捗の情報により、優先して取り組むべきバグを選定する。そして、元ソースコード８１において、バグ票１５に記入され前記バグを表現している文字列を元ソースコード８１全体に対して検索することにより同種のバグが存在する可能性がある箇所を特定する。さらに、対処修正した修正後ソースコード８２における修正位置を検索し、前記バグ票１５と前記検索された修正後ソースコード８２の修正箇所とを参照しながら修正内容を確認する。【選択図】  図９
2005228241.tif 000002
【特許請求の範囲】
【請求項１】
電子化された複数のバグ票を最新の入力日が古いものから順に並べ替える工程と、
前記古い順に並び替えられた複数のバグ票を重要度が高いものから順に並べ替える工程とを備えることを特徴とするバグ管理方法。
【請求項２】
請求項１に記載されたバグ管理方法において、
前記バグ票を、該バグ票に記録されたバグのプロジェクト進捗に対するダメージが大きいものから順に並べ替える工程をさらに備えることを特徴とするバグ管理方法。
【請求項３】
請求項１又は２に記載されたバグ管理方法において、
前記バグ票を、同じ原因分類コードを持つ前記バグ票が連続するように並べ替える工程をさらに備えることを特徴とするバグ管理方法。
【請求項４】
請求項１乃至３のうち何れか１項に記載されたバグ管理方法において、
ソースコード中に発見されたバグ部分文字列を前記バグ票に記録する工程と、
前記バグ票に記録されたバグ部分文字列を、前記ソースコード全体に対して検索する工程とをさらに備えることを特徴とするバグ管理方法。
【請求項５】
請求項４に記載されたバグ管理方法において、
前記バグ部分文字列を修正した修正後ソースコードにおける前記バグ部分文字列の修正位置を前記バグ票に記録する工程をさらに備えることを特徴とするバグ管理方法。
【請求項６】
電子化された複数のバグ票を最新の入力日が古いものから順に並べ替える手段と、
前記古い順に並び替えられた複数のバグ票を重要度が高いものから順に並べ替える手段とを備えることを特徴とするバグ管理装置。
【請求項７】
請求項６に記載されたバグ管理装置において、
前記バグ票を、該バグ票に記録されたバグのプロジェクト進捗に対するダメージが大きいものから順に並べ替える手段をさらに備えることを特徴とするバグ管理装置。
【請求項８】
請求項６又は７に記載されたバグ管理装置において、
前記バグ票を、同じ原因分類コードを持つ前記バグ票が連続するように並べ替える手段をさらに備えることを特徴とするバグ管理装置。
【請求項９】
請求項６乃至８に記載されたバグ管理装置において、
ソースコード中に発見されたバグ部分文字列を前記バグ票に記録する手段と、
前記バグ票に記録されたバグ部分文字列を、前記ソースコード全体に対して検索する手段とをさらに備えることを特徴とするバグ管理装置。
【請求項１０】
請求項９に記載されたバグ管理装置において、
前記バグ部分文字列を修正した修正後ソースコードにおける前記バグ部分文字列の修正位置を前記バグ票に記録する手段をさらに備えることを特徴とするバグ管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア開発プロセスにおけるバグ管理方法および装置に関し、特にバグ修正の進捗管理を助けるものに関する。
【背景技術】
【０００２】
従来のソフトウェア開発プロジェクトでは、品質管理の観点から、一度発生した不具合は二度と発生しないように支援する、品質問題フォロー方法及び支援システムがあった（例えば特許文献１参照）。
【特許文献１】特開２００３−１８７０６９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上記従来の技術には以下の問題がある。すなわち、ソフトウェア開発プロジェクトにおいては、開発の下流段階であるシステムテスト工程においてもしばしば数百個を超える大量のバグが発見される。当該ソフトウェア開発プロジェクトは、当然これらのバグの一つ一つに対して原因を特定しソフトウェアの修正を行う必要がある。しかし、これらのバグの一つ一つに対して、類似のバグが他にも存在することを見逃して順次異なるバグの対応を進めるのは効率的ではない。
【０００４】
本発明は、かかる点に鑑みてなされたものであり、その目的とするところは、ソフトウェア開発プロジェクトにおいて、優先して取り組むべきバグに対して類似するバグを選定し対策修正することを支援することにより、特にデバッグにかかわるソフトウェア開発工数を改善できるようにすることにある。
【課題を解決するための手段】
【０００５】
上記課題を解決するため、請求項１の発明は、電子化された複数のバグ票を最新の入力日が古いものから順に並べ替える工程と、
前記古い順に並び替えられた複数のバグ票を重要度が高いものから順に並べ替える工程とを備えることを特徴とする。
【０００６】
請求項２の発明は、請求項１に記載されたバグ管理方法において、
前記バグ票を、該バグ票に記録されたバグのプロジェクト進捗に対するダメージが大きいものから順に並べ替える工程をさらに備えることを特徴とする。
【０００７】
請求項３の発明は、請求項１又は２に記載されたバグ管理方法において、
前記バグ票を、同じ原因分類コードを持つ前記バグ票が連続するように並べ替える工程をさらに備えることを特徴とする。
【０００８】
請求項４の発明は、請求項１乃至３のうち何れか１項に記載されたバグ管理方法において、
ソースコード中に発見されたバグ部分文字列を前記バグ票に記録する工程と、
前記バグ票に記録されたバグ部分文字列を、前記ソースコード全体に対して検索する工程とをさらに備えることを特徴とする。
【０００９】
請求項５の発明は、請求項４に記載されたバグ管理方法において、
前記バグ部分文字列を修正した修正後ソースコードにおける前記バグ部分文字列の修正位置を前記バグ票に記録する工程をさらに備えることを特徴とする。
【００１０】
請求項６の発明は、電子化された複数のバグ票を最新の入力日が古いものから順に並べ替える手段と、
前記古い順に並び替えられた複数のバグ票を重要度が高いものから順に並べ替える手段とを備えることを特徴とする。
【００１１】
請求項７の発明は、請求項６に記載されたバグ管理装置において、
前記バグ票を、該バグ票に記録されたバグのプロジェクト進捗に対するダメージが大きいものから順に並べ替える手段をさらに備えることを特徴とする。
【００１２】
請求項８の発明は、請求項６又は７に記載されたバグ管理装置において、
前記バグ票を、同じ原因分類コードを持つ前記バグ票が連続するように並べ替える手段をさらに備えることを特徴とする。
【００１３】
請求項９の発明は、請求項６乃至８に記載されたバグ管理装置において、
ソースコード中に発見されたバグ部分文字列を前記バグ票に記録する手段と、
前記バグ票に記録されたバグ部分文字列を、前記ソースコード全体に対して検索する手段とをさらに備えることを特徴とする。
【００１４】
請求項１０の発明は、請求項９に記載されたバグ管理装置において、
前記バグ部分文字列を修正した修正後ソースコードにおける前記バグ部分文字列の修正位置を前記バグ票に記録する手段をさらに備えることを特徴とする。
【発明の効果】
【００１５】
以上のように、請求項１乃至３のうち何れか１項に係るバグ管理方法によれば、バグ修正プロセスの進捗を的確に把握することが可能となる。
【００１６】
さらに、請求項４又は５に係るバグ管理方法によれば、バグの修正内容を把握することにより同種のバグを容易に発見することができる。
【００１７】
請求項６乃至８のうち何れか１項に係るバグ管理装置によれば、バグ修正プロセスの進捗を的確に把握することが可能となる。
【００１８】
さらに、請求項９又は１０に係るバグ管理装置によれば、バグの修正内容を把握することにより同種のバグを容易に発見することができる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施形態を図面に基づいて詳細に説明する。以下の好ましい実施形態の説明は、本質的に例示に過ぎず、本発明、その適用物或いはその用途を制限することを意図するものでは全くない。
【００２０】
（１）ソフトウェア開発プロセス
図１は、本発明の一実施形態であるバグ分析装置を用いたソフトウェア開発プロセスを示す。一般に、ソフトウェア開発プロセスは、ウォーターフォール型と呼ばれる一方向に開発を進めるモデルにより説明される。ウォーターフォール型モデルは、計画工程１１、設計工程１２、実装工程１３、検証工程１４を有している。なお、設計工程１２、実装工程１３、検証工程１４を繰り返すことにより完成度を向上させながら開発を進めるスパイラル型モデルなども、ウォーターフォール型モデルの一変形だと考えることが可能である。
【００２１】
ソフトウェア開発プロジェクトの各プロセスで発見される不適切な設計又は実装をバグと呼ぶ。一般に、バグはそれが発見される工程が後工程であればあるほど、対処修正するためのコストが高くなる。すなわち、バグはそれが混入した工程で発見され対処修正されるのが、コストの観点から理想的である。ソフトウェア開発プロセスの中でも下流工程である検証工程１４のシステムテストにおいて発見されるバグは、コーディングを行う実装工程１３だけでなく、抽象的レベルでの設計を行う設計工程１２や、場合によっては要件定義を行う計画工程１１にまで手戻りすることがあり、開発コストの観点から当該ソフトウェア開発プロジェクトに対して大きなダメージを負わせていると言える。
【００２２】
前記検証工程１４のシステムテストにおいて発見されるバグは、バグ票１５と呼ばれるフォーマットに電子的に記録される。バグ票１５は、バグを発見した時に起票される。
【００２３】
前記検証工程１４のシステムテストにおいてバグが発見されなくなれば、ソフトウェアはリリースされ、当該ソフトウェア開発プロジェクトは完了し、完成されたソフトウェアは出荷１１１される。
【００２４】
（２）バグ票
以下、図２を参照しながら、本実施形態に係るバグ票１５のフォーマット及びバグの修正プロセスについて説明する。
【００２５】
バグ票１５は、検証工程１４のシステムテストにおいてバグが発見されたときに、プロジェクトＩＤ２０１、バグ票番号２０２、発見日２１１、発見者名２１２、一次現象２１３を記録することにより起票される。そして、前記一次現象２１３を確認したときに、現象確認日２２１、現象確認者名２２２、現象詳細２２３を記録することによりバグを確定する。
【００２６】
次に、バグの重要度を評価したときに、重要度評価日２３１、重要度評価者名２３２、重要度評価結果２３３を記録することにより対処修正の優先度を決定する。そして、バグの原因と対処修正策を特定したときに、対策決定日２４１、対策決定者名２４２、原因２４３、原因分類２４４、対策２４５を記録することにより対処修正を開始する。さらに、対処修正を完了したときに、修正完了日２５１、修正者名２５２、修正内容２５３、修正元文字列２５４、修正位置２５５を記録することにより再テストを開始する。さらに、再テストを完了したときに、再テスト完了日２６１、再テスト者名２６２、再テスト結果２６３を記録することにより完了判定を開始する。そして、完了判定を行ったときに、完了判定日２７１、完了判定者名２７２、完了判定結果２７３、ダメージ量２７４を記録することにより当該バグの修正プロセスを終了する。
【００２７】
図３に示すように、本実施形態では、バグ票１５はソフトウェア開発プロジェクトの組織の共用サーバ３１上に設置されるバグ票データベース３１１に蓄積される。共用サーバ３１はＬＡＮ３２を経由してソフトウェア開発プロジェクトの各メンバーの作業端末３３からアクセスできる。共用サーバ３１は、バグ票データベース３１１、バグ進捗管理表３１２、バグデータベース１８を備えている。以下説明するように、ソフトウェア開発プロジェクトの各メンバーは、このバグ票データベース３１１にアクセスすることにより、電子化されたバグ票１５に記入する。
【００２８】
前記検証工程１４のシステムテストにおいて、システムテスト担当者がバグを発見したときに本システムにログインし、図２に示すようにバグ票起票のメニューを選択すると、システムの時刻情報から発見日２１１、ログイン情報から発見者名２１２が自動入力される。また、発見者名２１２に対応する担当プロジェクトがメニューとして表示されるので、システムテスト担当者がプロジェクトＩＤ２０１を選択入力する。プロジェクトＩＤ２０１が決定すると、バグ票番号２０２が付与され自動入力される。また、システムテスト担当者が一次現象２１３を入力する。以上により、バグ票１５が起票される。
【００２９】
次に、前記バグ票１５が起票されると、プロジェクトＩＤ２０１に対応するプロジェクトの開発メンバーに前記起票されたバグ票情報がメール送信される。当該プロジェクトの開発メンバーが開発環境において前記一次現象２１３を確認したときに本システムにログインし、現象確認のメニューを選択すると、システムの時刻情報から現象確認日２２１、ログイン情報から現象確認者名２２２が自動入力される。また、前記開発メンバーが現象詳細２２３を入力する。以上により、バグが確定される。
【００３０】
次に、前記バグが確定すると、プロジェクトＩＤ２０１に対応するプロジェクトのプロジェクトリーダ及びその代理者に前記記入されたバグ票情報がメール送信される。当該プロジェクトのプロジェクトリーダ又はその代理者が前記バグの重要度を評価したときに本システムにログインし、重要度評価のメニューを選択すると、システムの時刻情報から重要度評価日２３１、ログイン情報から重要度評価者名２３２が自動入力される。また、前記プロジェクトリーダ又はその代理者が重要度評価結果２３３をメニューから選択入力する。
【００３１】
そして、バグが確定すると、プロジェクトＩＤ２０１に対応するプロジェクトのプロジェクトリーダ及びその代理者に前記記入されたバグ票情報がメール送信されるとともに、後で図３により説明する、バグ進捗管理表３１２に表示される。バグ進捗管理表３１２は、当該ソフトウェア開発プロジェクトの全メンバーが参照できる。バグ進捗管理表３１２には、進捗状態のほか、バグの重要度評価結果２３３をはじめバグ票１５に記録されている情報が表示される。確定したばかりのバグの進捗状態は、調査中となる。
【００３２】
次に、プロジェクトＩＤ２０１に対応するプロジェクトの開発メンバーは、バグの原因を追求し、対処修正案を策定する。当該プロジェクトの開発メンバーが前記バグの原因を追求し、対処修正案を策定したときに本システムにログインし、原因入力のメニューを選択すると、システムの時刻情報から対策決定日２４１、ログイン情報から対策決定者名２４２が自動入力される。また、前記開発メンバーが原因２４３、対策２４５を入力し、原因分類２４４をメニューから選択入力する。これにより、バグ進捗管理表３１２に当該バグの進捗状態が反映され、修正中となる。
【００３３】
次に、プロジェクトＩＤ２０１に対応するプロジェクトの開発メンバーは、対処修正を行う。当該プロジェクトの開発メンバーが前記バグの対処修正を完了したときに本システムにログインし、修正完了のメニューを選択すると、システムの時刻情報から修正完了日２５１、ログイン情報から修正者名２５２が自動入力される。また、前記開発メンバーが修正内容２５３、修正元文字列２５４、修正位置２５５を入力する。これにより、バグ進捗管理表３１２に当該バグの進捗状態が反映され、再テスト中となる。
【００３４】
次に、前記修正が完了すると、プロジェクトＩＤ２０１を担当するシステムテスト担当者に前記記入されたバグ票情報がメール送信される。当該プロジェクトのシステムテスト担当者が再テストを完了したときに本システムにログインし、再テストのメニューを選択すると、システムの時刻情報から再テスト完了日２６１、ログイン情報から再テスト者名２６２が自動入力される。また、前記システムテスト担当者が再テスト結果２６３をメニューから選択入力する。これにより、バグ進捗管理表３１２に当該バグの進捗状態が反映され、判定中となる。
【００３５】
次に、前記再テストが完了すると、プロジェクトＩＤ２０１に対応するプロジェクトのプロジェクトリーダ及びその代理者に前記記入されたバグ票情報がメール送信される。当該プロジェクトのプロジェクトリーダ又はその代理者が完了判定を行ったときに本システムにログインし、完了判定のメニューを選択すると、システムの時刻情報から完了判定日２７１、ログイン情報から完了判定者名２７２が自動入力される。また、前記プロジェクトリーダ又はその代理者が完了判定結果２７３とダメージ量２７４とをメニュー入力する。これにより、バグ進捗管理表３１２に当該バグの進捗状態が反映され、バグの修正プロセスが完了する。
【００３６】
なお、図２では、自動入力部分を細線、メニュー入力部分を太破線、ユーザによる手入力部分を太実線により表した。
【００３７】
（３）バグ票の項目の省略
上記説明では、本実施形態におけるバグ票１５の項目を示したが、採用するソフトウェア開発標準によっては、使用するバグ票１５が必ずしも前記したすべての項目を含む必要はなく、前記項目を部分的に含むバグ票１５を使用しても差し支えない。当然その場合には、上記で説明したバグの修正プロセスも部分的に省略される。ただし、原因分類２４４は必須の項目である。
【００３８】
また、後述するダメージの評価において、ダメージ量２７４を使用する場合には、ダメージ量２７４は必須の項目である。さらに、バグ修正に要した日数を使用する場合には、発見日２１１及び完了判定日２７１は必須の項目である。ただし、採用するソフトウェア開発標準によっては、発見日２１１の代わりに現象確認日２２１、完了判定日２７１の代わりに再テスト完了日２６１や修正完了日２５１を使用することにして、これを発見日２１１や完了判定日２７１の代わりに必須の項目としても構わない。
【００３９】
（４）原因分類
本実施形態における前記バグ票１５の原因分類２４４を、図４の分類表に示す。原因分類２４４は、ソフトウェア開発プロセスにおける技術的対策に結びつけるために、直接的な技術的原因として分類する。
【００４０】
以下、図５を用いて、本実施形態での原因入力の方法について説明する。前記バグ票１５の原因分類２４４の入力では、まずメニューによりソフトウェア開発プロセスなどによる大分類を選択する。すなわちユーザは、要求分析やシステム設計、ソフトウェアアーキテクチャ設計といった上流工程５１、ソフトウェア機能設計やソフトウェアモジュール設計といった中流工程５２、コーディングにあたる下流工程５３、及びテストのミスやハードウェアのバグなどによるその他５４の４つの分類から選択する。前記大分類が行われると、そのままさらに詳細分類のメニューを表示する。ここで、詳細分類は、前記ソフトウェア開発プロセスなどによる大分類に含まれるバグの技術的原因である。
【００４１】
前記大分類として前記上流工程５１を選択した場合には、詳細分類として、不適切５１１、要求変更／追加（定義抜け）５１２、要求変更／追加（ユーザ）５１３、性能見積もりの誤り５１４、バッファサイズが小さい５１５、データフローが冗長５１６、プログラムの自由度が低い５１７、誤差／精度見積もりミス５１８、オーバーフロー／アンダーフロー５１９がメニュー表示され、ユーザはいずれかを選択する。
【００４２】
前記大分類として前記中流工程５２を選択した場合には、詳細分類として、処理誤り（不完全な正常系処理）５２１、処理抜け（異常系見落とし）５２２、状態チェック抜け（正常系見落とし）５２３、処理はじめの初期化抜け５２４、状態遷移時の初期化抜け５２５、排他処理の誤り５２６、タイミングなど時間的境界５２７、数値的境界５２８、アドレスなど空間的境界５２９、メモリマップの誤り５２１０がメニュー表示され、ユーザはいずれかを選択する。
【００４３】
前記大分類として前記下流工程５３を選択した場合には、詳細分類として、実装忘れ５３１、不適切なモジュール分割５３２、使用する下位関数の選択間違い５３３、型の誤り５３４、引数異常５３５、定数の異常５３６がメニュー表示され、ユーザはいずれかを選択する。
【００４４】
前記大分類として前記その他５４を選択した場合には、詳細分類として、デバッグ時の修正ミス／副作用５４１、ハードウェアのバグ５４２、マイクロコードのバグ５４３、テスト操作の誤り５４４、その他５４５がメニュー表示され、ユーザはいずれかを選択する。
【００４５】
本実施形態では、上記のように合計約３０種類からなるバグの技術的原因を詳細分類として設定し、４種類からなる大分類に分類した。本発明を実施する場合には、選択が煩雑にならない範囲で、バグの技術的原因をさらに詳細に分類しても構わない。また逆に、バグの技術的原因としてほとんど発生しないと考えられる場合には、詳細分類から省略しても構わない。ただし、詳細分類を大括りな分類にすると、技術的な対策を立てにくくなるので好ましくない。
【００４６】
（５）ダメージ量の評価
次に、本発明の実施形態におけるダメージ量の評価方法について、図６を用いて説明する。前記バグ票１５におけるダメージ量２７４に、ユーザはバグごとにソフトウェア開発プロジェクトが受けたダメージを評価して入力する。このダメージとは、主に開発工数の損失であり、例えばバグの結果として支払うことになった損失ではない。
【００４７】
本実施形態では、ダメージ量２７４の入力時に以下のメニューを表示する。すなわち、軽微であり即日修正及び確認６０、確認終了まで１人日以上２人日未満を要した６１、確認終了まで２人日以上５人日未満を要した６２、確認終了まで５人日以上１５人日未満を要した６３、確認終了まで１５人日以上３０人日未満を要した６４、確認終了まで３０人日以上を要した６５の６段階にバグによるダメージを分類する。
【００４８】
そして、バグの技術的原因ごとに、ダメージとして、軽微であり即日修正及び確認６０の場合は当該バグ原因のダメージ量に０を加算し、確認終了まで１人日以上２人日未満を要した６１の場合は当該バグ原因のダメージ量に１を加算し、確認終了まで２人日以上５人日未満を要した６２の場合は当該バグ原因のダメージ量に２を加算し、確認終了まで５人日以上１５人日未満を要した６３の場合は当該バグ原因のダメージ量に３を加算し、確認終了まで１５人日以上３０人日未満を要した６４の場合は当該バグ原因のダメージ量に４を加算し、確認終了まで３０人日以上を要した６５の場合は当該バグ原因のダメージ量に５を加算する。
【００４９】
本発明の、上記とは別の実施形態におけるダメージ量の評価方法を、図２を用いて説明する。
【００５０】
バグ票１５に記入されている発見日２１１から完了判定日２７１までの日数を、プロジェクトに与えたダメージとして、当該バグ原因のダメージ量として加算する。本実施形態では、発見日２１１から完了判定日２７１までの日数の算出方法として、単純に暦日を用いているが、別途プロジェクトの稼働日をカレンダー上に定義することにより休日などの非稼動日を含まない日数を算出しても構わない。
【００５１】
（６）バグ票の蓄積
図１及び図３を用いて、本発明の実施形態に係るバグ票１５の蓄積方法について説明する。ソフトウェア開発プロジェクトの各メンバーは、それぞれの作業端末３３からＬＡＮ３２を経由して共用サーバ３１上のバグ票データベース３１１、バグ進捗管理表３１２、バグデータベース１８にアクセスすることができる。
【００５２】
上記で説明したように、バグが発見されると、バグ票データベース３１１にバグ票１５が起票され、バグ票１５に順次必要事項を記入する。こうして、バグの数だけバグ票１５がバグ票データベース３１１に蓄積される。
【００５３】
同じプロジェクトのバグ票１５は、バグ票１５のプロジェクトＩＤ２０１に記入されている値が同一であるものである。
【００５４】
（７）バグ進捗管理表の作成
図１及び図７を用いて、本発明の実施形態に係るバグ進捗管理表３１２の作成方法について説明する。バグ進捗管理表３１２は、バグ票１５に記入されている情報を一覧できるように並べたものである。本実施形態では、バグ票１５を並べる順序が重要になる。
【００５５】
まず、バグ票１５のうち、同じ原因分類２４４を持つバグ票１５を１つのグループ７１として集める。ここで、前記グループ７１はグループデータ７２を備えており、また、前記グループデータ７２はメンバー表７２１を備えている。なお、前記グループ７１は、最大で原因分類２４４の種類の数だけ存在する。
【００５６】
そして、同じ原因分類２４４を持つバグ票１５のバグ票番号２０２が、メンバー表７２１に順次書き込まれる。ここで、前記メンバー表７２１はリスト構造となっている。
【００５７】
次に、メンバー表７２１に書き込まれているバグ票１５を、前記バグ票１５の最新更新日が古いものから順に並べ替える。すなわち、バグ票１５に完了判定日２７１が記入されていれば完了判定日２７１を最新更新日として採用する。完了判定日２７１が空欄であれば再テスト完了日２６１を参照し、再テスト完了日２６１が記入されていれば再テスト完了日２６１を最新更新日として採用する。さらに再テスト完了日２６１が空欄であれば修正完了日２５１を参照し、修正完了日２５１が記入されていれば修正完了日２５１を最新更新日として採用する。さらに修正完了日２５１が空欄であれば対策決定日２４１を参照し、対策決定日２４１が記入されていれば対策決定日２４１を最新更新日として採用する。さらに対策決定日２４１が空欄であれば重要度評価日２３１を参照し、重要度評価日２３１が記入されていれば重要度評価日２３１を最新更新日として採用する。さらに重要度評価日２３１が空欄であれば現象確認日２２１を参照し、現象確認日２２１が記入されていれば現象確認日２２１を最新更新日として採用する。さらに現象確認日２２１が空欄であれば発見日２１１を最新更新日として採用する。これにより、メンバー表７２１の先頭のバグ票１５は、最新更新日が最も古いバグ票となる。
【００５８】
次に、メンバー表７２１に書き込まれているバグ票１５を、最も重要度の高いものが先頭となるように順に並べ替える。すなわち、バグ票１５に書き込まれている重要度評価結果２３３を参照する。重要度評価が終了していないバグ票１５は、重要度が最も低いレベルを採用する。
【００５９】
以上のようなバグ票１５の並べ替えを行うことにより、メンバー表７２１の先頭のバグ票１５は、グループ７１の中で最も重要度が高く、また同じ重要度の中で最も長期間にわたって進捗が進んでいないバグ票１５となる。
【００６０】
（８）バグ文字列の検索
次に、本発明の実施形態に係るバグ文字列の検索方法を図８を用いて説明する。まず、バグ票１５の修正元文字列２５４に記入されている文字列を、元ソースコード８１全体に対してエディタなどで文字列検索する。これにより、元ソースコード８１中において同種のバグが存在する可能性がある箇所を指摘することが可能となる。
【００６１】
このように、バグを対処修正することにより、修正者は元ソースコード８１においてバグが存在した箇所の文字列を特定することが可能である。図８の例では、修正者は文字列「うい」をバグの文字列と考える。ここで、バグの文字列を例えば「あういえお」と考えても構わない。このとき、このバグの文字列と同じ間違いをしている他のバグを検索するために、適切な文字列を選定することが必要である。
【００６２】
そして、元ソースコード８１中で前記バグの特徴を良く表現していて、他の同種のバグと共通すると考えられる文字列を修正元文字列２５４として入力し記録する。このバグ文字列の入力には、作業端末のパーソナルコンピュータのＯＳやエディタにおける文字列コピー機能を用いる。
【００６３】
（９）修正位置の検索
次に、本発明の実施形態に係る修正位置の検索方法を図９を用いて説明する。まず、バグ票１５の修正位置２５５に記入されている位置情報をエディタなどで表示する。これにより、修正後ソースコード８２中の修正箇所を参照することが可能となる。
【００６４】
このように、バグを対処修正することにより、修正者は元ソースコード８１を修正した修正後ソースコード８２中の修正箇所を特定することが可能である。図９の例では、修正者は３行目２文字目から３行目３文字目までの「いう」を修正箇所と考える。ここで、修正箇所を例えば「あいうえお」と考えても構わない。このとき、前記バグ票１５に関する修正後ソースコード８２中の修正箇所を表すのに適切な箇所を示すことが必要である。
【００６５】
そして、エディタ上の修正後ソースコード８２中の修正箇所及びその範囲を指示することにより、ソースコードファイルにおける修正箇所及びその範囲情報を修正位置２５５として入力し記録する。この修正箇所の入力には、作業端末のパーソナルコンピュータのエディタにおける文字列位置表示機能を用いる。
【産業上の利用可能性】
【００６６】
本発明に係るバグ管理方法および装置は、ソフトウェア開発プロジェクトのプロセス改善を支援するツールとして有用である。
【図面の簡単な説明】
【００６７】
【図１】本発明の実施形態に係るソフトウェア開発プロセスを示す図である。
【図２】本発明の実施形態に係るバグ票を示す図である。
【図３】本発明の実施形態に係るバグデータベースを示す図である。
【図４】本発明の実施形態に係るバグの原因分類表を示す図である。
【図５】本発明の実施形態に係るバグ原因分類入力を示す図である。
【図６】本発明の実施形態に係るダメージ量の評価を示す図である。
【図７】本発明の実施形態に係るバグ進捗管理票作成の方法を示す図である。
【図８】本発明の実施形態に係るバグ文字列の検索方法を示す図である。
【図９】本発明の実施形態に係る修正位置の検索方法を示す図である。
【符号の説明】
【００６８】
１１    計画工程
１２    設計工程
１３    実装工程
１４    検証工程
１５    バグ票
１８    バグデータベース
１１１  出荷
２０１  プロジェクトＩＤ
２０２  バグ票番号
２１１  発見日
２１２  発見者
２１３  一次現象
２２１  現象確認日
２２２  現象確認者
２２３  現象詳細
２３１  重要度評価日
２３２  重要度評価者
２３３  重要度評価結果
２４１  対策決定日
２４２  対策決定者
２４３  原因
２４４  原因分類
２４５  対策
２５１  修正完了日
２５２  修正者
２５３  修正内容
２５４  修正元文字列
２５５  修正位置
２６１  再テスト完了日
２６２  再テスト者
２６３  再テスト結果
２７１  完了判定日
２７２  完了判定者
２７３  完了判定結果
２７４  ダメージ量
３１    共用サーバ
３１１  バグ票データベース
３１２  バグ進捗管理表
３２    ＬＡＮ
３３    作業端末
５１    上流工程
５２    中流工程
５３    下流工程
５４    その他
７１    グループ
７２    グループデータ
７２１  メンバー表
８１    元ソースコード
８２    修正後ソースコード
【図１】
2005228241.tif 000003
【図２】
2005228241.tif 000004
【図３】
2005228241.tif 000005
【図４】
2005228241.tif 000006
【図５】
2005228241.tif 000007
【図６】
2005228241.tif 000008
【図７】
2005228241.tif 000009
【図８】
2005228241.tif 000010
【図９】
2005228241.tif 000011