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