JP2014203330A

JP2014203330A - プロダクト品質評価装置及び方法

Info

Publication number: JP2014203330A
Application number: JP2013080295A
Authority: JP
Inventors: 三宅　武司; Takeshi Miyake; 武司三宅; 田中　弘一; Koichi Tanaka; 弘一田中
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2013-04-08
Filing date: 2013-04-08
Publication date: 2014-10-27

Abstract

【課題】リリース後のソフトウェアによる障害件数を予測することを可能とし、また、残存バグの進捗状況を知ることを可能にする。
【解決手段】本発明は、バグ毎のバグ検出時間、バグ発見件数を取得し、最も適合度の高い信頼度成長モデルの平均値関数を用いて該バグ発見件数の累積件数から残存バグを推定し、前記平均値関数を１回微分することにより求められたバグ生起確率関数を用いてバグ生起確率を求め、該バグ生起確率を用いてバグ生起確率曲線を描画し、バグ生起確率曲線から残存バグの収束状況を分類し、品質達成状況として出力し、収束状況判定手段による残存バグの収束状況から品質達成状況を評価し、残存バグの件数、残存バグの収束率及び残存バグの収束状況から総合評価を行う。
【選択図】図１

Description

本発明は、プロダクト品質評価装置及び方法に係り、特に、ソフトウェア開発過程の試験工程以降における品質情報から残存バグ件数を予測するためのプロダクト品質評価装置及び方法に関する。

情報システムが経済・社会の様々な分野で必要不可欠なものとなっている現在、信頼性の高いソフトウェア開発に対する要求が高まっている。信頼性の高いソフトウェアを開発するためには、ソフトウェア品質を定量的に評価し、残存バグ件数を高い精度で予測することが、当該ソフトウェアを用いたサービスの開始の判断を適切に実施するためにも不可欠である。

残存バグ件数を推定する方法として広く利用されているのは、試験工程で検出されるバグの累積値の傾向から残存バグ件数を推定するソフトウェア信頼度成長モデル（Software Reliability Growth Model: SRGM）がある。SRGMは、試験工程で検出される欠陥の発生事象の動的挙動を確率モデルにより表現したものであり、欠陥除去作業によりソフトウェアの信頼性が向上する。

SRGMを用いた手法としては、横軸に時間情報（日付、テスト時間、テストケース数）、縦軸に累積バグ発見数をとったグラフであるソフトウェア信頼度成長曲線(Software Reliability Growth Curve)に関して、複数のモデルによる統合モデルを導出する手順がある（例えば非特許文献１参照）。

また、複数のソフトウェア信頼度成長モデルの評価が可能であり、予測残存バグ件数などの数値データ、更にはグラフレポート機能として平均値関数、残存バグ率などをグラフ表示できる技術がある（例えば、非特許文献２参照）。

古山恒夫：ソフトウェア新ランド成長モデルに関する統合モデルの解析的パラメータ推定法,情報処理学会論文誌, Vol. 37, No.12 1996. 岡村寛之、安藤光昭、土肥正、表計算ソフトウェアによるソフトウェア信頼性評価ツール（SRATS）の開発、電子情報通信学会論文誌（D-I）,vol. J88-D-I, no. 2, pp. 205-214, 2005.

しかしながら、上記従来の方法では、累積バグ件数の予測曲線の収束判定は、試験観点の網羅性や試験進捗状況など多くの情報を基に判定する必要があるため、経験者でなければ正確な収束判定を行うことは不可能である。

残存バグ件数の予測においては、適切な品質評価モデルを複数用いることで、その信頼性を高めることが推奨されている（例えば、非特許文献３：S. H. Kan, "Metrics and Models in Software Quality Engineering (2^nd Edition), Addison-Wesley Professional; (2002).）。複数のモデルによる予測が一貫していれば、予測の信頼性は高まり、逆に複数のモデルによる予測が一貫していなければ、その差異の理解、原因の確認等を行った上での総合的な判断が必要になる。ソフトウェア信頼度成長モデルとレイリーモデルは、共に一般的に行われている故障処理票などの品質管理データで評価が可能であり、特別なデータを取得する必要がないため、比較的容易に適用可能であると考えられる。このため、この両モデルによる残存バグ件数の予測が、どういった条件の時に一致するのか、あるいはどのような時に不整合が発生するのかを実証的に明らかにすることは、これらのモデルを用いて残存バグ件数の予測を行う際の有益である。

しかし、これらの複数の品質予測モデルを用いた場合の実証結果の比較は、システム開発において、個別の開発の傾向が強く、同一開発条件での比較が困難であるため、これまでの研究では十分に行われていない。実開発においては、業務仕様、システム構成、開発手順、要求定義の品質、仕様変更の有無など、品質に影響を与える様々な条件が数多く存在すると考えられるが、実開発の複数のプロジェクトでそれら様々な条件を同一とすることは基本的に困難である。

本発明は、上記の点に鑑みなされたもので、ソフトウェア信頼度成長モデルを用いて残存バグ件数を予測し、リリース後のソフトウェアによる障害件数を予測することを可能とし、また、バグ生起確率を求めることで残存バグの進捗状況を知ることが可能なプロダクト品質評価装置及び方法を提供することを目的とする。

上記の課題を解決するため、本発明（請求項１）は、ソフトウェアの試験工程で検出されるバグの発生事象の動的挙動を確率モデルにより表現した信頼度成長モデルを用いてプロダクトの品質を評価するプロダクト品質評価装置であって、
バグ毎のバグ検出時間、バグ発見件数を取得し、最も適合度の高い信頼度成長モデルの平均値関数を用いて該バグ発見件数の累積件数から残存バグ件数を推定するバグ数推定手段と、
前記平均値関数を１回微分することにより求められたバグ生起確率関数を用いてバグ生起確率を求め、該バグ生起確率を用いてバグ生起確率曲線を描画するバグ生起確率曲線出力手段と、
前記バグ生起確率曲線から残存バグの収束状況を分類し、品質達成状況として出力する収束状況判定手段と、
前記収束状況判定手段による前記残存バグの収束状況から品質達成状況を評価する品質状況評価手段と、
前記残存バグの件数、残存バグの収束率及び前記残存バグの収束状況から総合評価を行う品質総合判定手段と、を有する。

また、本発明（請求項２）は、前記収束状況判定手段において、
前記バグ生起確率曲線から、
前記バグ生起確率曲線が残存バグ０件に収束しない；
試験が進行しているにも関わらず、前記バグ生起確率曲線値が増加、または、低下しない；
前記バグ生起確率曲線が残存バグ０件に収束；
のいずれかに分類し、品質達成状況として出力する手段を含む。

また、本発明（請求項３）は、前記品質状況評価手段において、
前記残存バグの収束状況に基づいて、
試験が足りないため、追加試験または強化試験が必要；
試験観点、試験実施方法に不備があるため、試験計画を見直す必要がある；
試験完了；
のいずれであるかを判定し、判定結果を前記品質達成状況として出力する手段を含む。

また、本発明（請求項４）は、前記品質総合判定手段において、
前記残存バグの件数、残存バグの収束率、前記残存バグの収束状況と、それぞれの閾値とを比較して、
試験が足りないため、追加試験または、強化試験が必要であるため、品質達成度は不十分；
試験観点、試験実施方法に不備があるため、試験計画を見直す必要があるため、品質達成度は不十分；
品質状況は良好なため、試験を終了；
のいずれであるかを判定する手段を含む。

上述のように本発明によれば、まず、信頼度成長モデルにおいて試験工程のバグ発生件数と、発生時刻からリソース判定時に、ソフトウェアに含まれる残存バグ件数を予測することにより、リリース後のソフトウェアによる障害係数を予測することができる。

また、信頼度成長モデルに用いた信頼度モデルの平均値関数を、微分することによりバグ生起確率を求め、得られたバグ生起確率関数に、実際のバグ情報を投入しバグ生起確率関数値を求めることにより、残存バグの進行状況を知ることができる。

残存バグの状況を把握することにより、追加試験の必要の有無や、試験計画の見直しの必要性の情報を提供可能となり、正確に工程終了判断またはリソース判断を行うことができる。

本発明の一実施の形態におけるプロダクト品質評価装置の構成図である。本発明の一実施の形態における入力値情報の例である。本発明の一実施の形態におけるプロダクト品質評価装置の概要動作のフローチャートである。本発明の一実施の形態における信頼度成長モデルバグ数推定部の出力例である。本発明の一実施の形態におけるソフトウェア信頼度成長モデル計算部から出力されるバグ生起確率曲例である。本発明の一実施の形態におけるステップ１２０の詳細処理のフローチャートである。本発明の一実施の形態におけるステップ１３０の詳細処理のフローチャートである。本発明の一実施の形態におけるステップ１４０の詳細処理のフローチャートである。本発明の一実施の形態における信頼度成長モデルによる総合品質評価の例である。

以下、図面と共に本発明の実施の形態を説明する。

まず、以下の用語の定義を示す。

・バグ生起確率（関数）：試験開始時刻０から時刻ｔにおける１件のバグが発見される確率、または、その確率の関数；
・バグ生起確率曲線：バグ生起確率関数で描画された曲線グラフ；
・バグ生起確率関数値：バグ生起確率関数から得られた１件のバグが発見される確率；
・収束率：信頼度成長モデルにおいて予測される総バグ数に対する、時刻ｔまでに発見されたバグ数の累積値の比率。収束率が高いほど残存バグが少なく品質が良いと判断される；
・収束状況：信頼度成長モデルにおいて得られるバグ生起確率関数値。バグ生起確率関数値が０に近いほど残存バグが少ないと考えられ、収束率が高くなる。

・平均値関数：信頼度成長モデルにおいて、試験開始時刻０から時刻ｔまでに発見される累積バグ数の期待値を表す関数。単位は件数で表す。

・平均値関数計算値：平均値関数により求められた計算値；
・残存バグ収束状況情報：収束率、収束状況から得られる情報であり、収束率が１００％に近づかず、収束状況が０にならない場合、残存バグが十分に除去されていないと判定される。

・品質達成状況：品質状況が、収束率及び収束状況により達成されているのか否かの状況。収束状況により、「試験が十分に実施されていない（試験不足）」や、「試験の実施に不備がある」、「試験は十分」を判断する根拠となる情報；
図１は、本発明の一実施の形態におけるプロダクト品質評価装置の構成を示す。

同図に示すプロダクト品質評価装置１００は、信頼度成長モデルバグ数推定部１０、ソフトウェア信頼度成長モデル計算部１１０、収束状況判定部１２０、品質総合判定部１３０、メモリ１４０を有する。

信頼度成長モデルバグ数推定部１０は、ソフトウェア信頼度成長モデル計算部１１０の前処理を行うための手段であり、既存技術により実現可能である。

信頼度成長モデルバグ数推定部１０は、ユーザから図２に示すようなバグ毎のバグ発見時間を入力値情報として取得し、最も適合度の高い信頼度成長モデルの平均値関数（バグ成長曲線）を用い、バグ発見件数の累積件数から残存バグを推定し、当該残存バグ件数、評価に用いた平均値関数（バグ成長曲線）の計算値、収束率をソフトウェア信頼度成長モデル計算部１１０に出力する。平均値関数の例として、例えば、「山田茂、高橋宗雄、"ソフトウェアマネジメントモデル入門ソフトウェア品質の可視化と評価法"共立出版株式会社, p184」の技術を用いて、用いる関数モデル毎に求めることができる。

ソフトウェア信頼度成長モデル計算部１１０は、信頼度成長モデルバグ数推定部１０から入力されたバグ発見時間、残存バグ件数、信頼度成長モデルの評価に用いた平均値関数（バグ成長曲線）の計算値、収束率及びバグ生起確率関数算出部２０から入力されたバグ生起確率関数をメモリ１４０に格納し、これらの値を用いて、バグ生起確率の値を求め、求めた値に基づいてバグ生起確率曲線を描画し、収束状況判定部１２０に出力する。

収束状況判定部１２０は、ソフトウェア信頼度成長モデル計算部１１０から取得したバグ生起確率曲線から残存バグの収束状況を評価し、残存バグ収束判定結果を出力する。また、残存バグ件数と残存バグ収束判定結果を用いて品質状況を評価し、品質達成状況を品質総合判定部１３０に出力する。

品質総合判定部１３０は、残存バグ件数、平均値関数計算値、品質達成状況を用いて品質判定を行い、その結果を品質総合評価情報としてユーザに出力する。

図３は、本発明の一実施の形態におけるプロダクト品質評価装置の概要動作のフローチャートである。

ステップ１００）信頼度成長モデルバグ数推定部１０は、信頼度成長モデルにおいて、試験工程におけるバグ発生件数とバグ検出時間から平均値関数（バグ成長曲線）の収束状況と残存バグ件数を判断する。

具体的には、ユーザ端末１からバグ検出時間、バグ発生件数を取得して既存技術により、残存バグ件数、累積バグ収束度、バグ生起確率曲線を算出し、ソフトウェア信頼度成長モデル計算部１１０に出力する。バグ生起確率曲線は、例えば、非特許文献２の技術を用いて生成する。残存バグ予測情報の例を図４（ａ）に、バグ生成確率曲線情報を図４（ｂ）に示す。当該処理において試験工程のバグ発生件数と、リリース判定時に、バグ検出時間からソフトウェアに含まれる残存バグ件数を予測することにより、リリース後のソフトウェアによる障害件数を予測することができる。

ステップ１０２）ソフトウェア信頼度成長モデル計算部１１０は、信頼度成長モデルバグ数推定部１０から平均値関数を取得して１回微分してバグ生起確率関数を求める。なお、当該処理は、当該ソフトウェア信頼度成長モデル計算部１１０で行うのではなく、既存技術を用いて計算されたバグ生起確率関数を取得してもよい。

ステップ１１０）ソフトウェア信頼度成長モデル計算部１１０は、残存バグ件数、累積バグ収束度、バグ生起確率曲線、バグ生起確率関数を取得し、ステップ１００で選択された平均値関数に対応する、バグ生起確率関数、バグ毎のバグ発見時間、バグ生起確率関数を用いて、バグ生起確率の値を求め、求めた値に基づいてバグ生起確率曲線を描画する。バグ生起確率曲線の生成には、非特許文献２の技術を用いることができる。バグ生起確率曲線の例を図５に示す。同図では、縦軸に日付、テスト時間などの時間情報、縦軸に累積バグ発見数（Software Failure Rate）をとったグラフである。同図において、パターンａは残存バグが残っている状態を示し、パターンｂは試験進捗が異常であることを示し、パターンｃは残存バグが残っていないことを示す。

これにより、残存バグの進捗状況を知ることができる。

ステップ１２０）収束状況判定部１２０は、ソフトウェア信頼度成長モデル計算部１１０から出力されたバグ生起確率曲線の状況と、残存バグの収束状況を評価する。詳細な処理は図６で後述する。

ステップ１３０）収束状況判定部１２０は、残存バグ件数と残存バグ収束判定結果から品質状況を評価し、品質達成状況を品質統合判定部１３０に出力する。詳細な処理は図７で後述する。

ステップ１４０）品質総合判定部１３０は、残存バグ件数、平均値関数計算値、品質達成状況を取得して、信頼度成長モデルにより得られた情報を基に、品質判定を行う。詳細な処理は図８で後述する。

ステップ１５０）品質相当判定部１３０は、判定結果を出力する。

次に、上記のステップ１２０の処理について説明する。

図６は、本発明の一実施の形態におけるステップ１２０の詳細処理のフローチャートである。

ステップ１２２）収束状況判定部１２０は、ソフトウェア信頼度成長モデル計算部１０から出力されたバグ生起確率曲線による傾向を分析する。

具体的には、バグ生起確率曲線から残存バグ収束状況を以下の３つのパターンに分類する。

パターンａ：バグ生起確率曲線が残存バグ件数＝０に収束しない。

パターンｂ：試験が進行しているにも関わらず、バグ生起確率曲線の値が増加、または低下しない。

パターンｃ：バグ生起確率曲線が残存バグ件数＝０に収束する。

例えば、図５の例では、パターンａのTruncated Logistic Modelでは、時間(T=15)辺りで15%の生起確率で、また、Gamma Modelにおいても時刻(T=30)辺りでバグが横ばい状態になっており、残存バグが残っていることを示している。したがって、パターンａの場合には、「残存バグが残っている」という傾向を残存バグ収束状況情報として出力する。

次に、上記のステップ１３０の処理の処理について説明する。

図７は、本発明の一実施の形態におけるステップ１３０の詳細処理のフローチャートである。

ステップ１３２）収束状況判定部１２０は、ステップ１２０で得られた残存バグ収束状況情報に基づき品質状況を評価する。

具体的には、残存バグ収束状況情報の各項目（AIC（赤池情報量基準）、バグ総数予測値、残存バグ件数予測値、Fault-Free Probability Conditional MTTF、Cumulative MTTF）毎に閾値を設定しておき、残存バグ収束状況情報の各項目の値と閾値を比較して以下の３つのパターンのいずれであるかを判定する。

パターンａ：試験が足りないため、追加試験または強化試験が必要。

パターンｂ：試験観点、試験実施方法に不備があるため、試験計画を見直す必要がある。

パターンｃ：試験完了
上記のいずれかのパターンを品質達成状況として出力する。

次に、上記のステップ１４０の処理について説明する。

図８は、本発明の一実施の形態におけるステップ１４０の詳細処理のフローチャートである。

ステップ１４２）品質総合判定部１３０は、ステップ１００で得られた残存バグ予測値、ステップ１２０で得られた残存バグ収束状況、ステップ１３０で得られた品質達成状況の各情報に基づいて、品質状況を判定する。

具体的には、残存バグ収束率、残存バグ件数、残存バグ収束状況から、以下の３つのパターンに対して品質を判定する。

パターンａ）試験が足りないため、追加試験または強化試験が必要であり、品質達成度は不十分。

パターンｂ）試験観点、試験実施方法に不備があるため、試験計画を見直す必要があるため、品質達成度は不十分。

パターンｃ）品質状況は良好なため、試験を終了。

上記のパターンａ，ｂ，ｃのいずれかを品質判定結果として出力する。例えば、図９の例では、評価結果として、プロジェクト毎に、残存バグ予測値、予測値の信頼度、品質状況パターン、総合品質評価等の項目からなるレコードを出力する。

上記の図１に示すプロダクト品質評価装置の各構成要素の動作をプログラムとして構築し、プロダクト品質評価装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１ユーザ端末
１０信頼度成長モデルバグ数推定部
２０バグ生起確率関数算出部
１００プロダクト品質評価装置
１１０ソフトウェア信頼度成長モデル計算部
１２０収束状況判定部
１３０品質総合判定部
１４０メモリ

Claims

ソフトウェアの試験工程で検出されるバグの発生事象の動的挙動を確率モデルにより表現した信頼度成長モデルを用いてプロダクトの品質を評価するプロダクト品質評価装置であって、
バグ毎のバグ検出時間、バグ発見件数を取得し、最も適合度の高い信頼度成長モデルの平均値関数を用いて該バグ発見件数の累積件数から残存バグ件数を推定するバグ数推定手段と、
前記平均値関数を１回微分することにより求められたバグ生起確率関数を用いてバグ生起確率を求め、該バグ生起確率を用いてバグ生起確率曲線を描画するバグ生起確率曲線出力手段と、
前記バグ生起確率曲線から残存バグの収束状況を分類し、品質達成状況として出力する収束状況判定手段と、
前記収束状況判定手段による前記残存バグの収束状況から品質達成状況を評価する品質状況評価手段と、
前記残存バグの件数、残存バグの収束率及び前記残存バグの収束状況から総合評価を行う品質総合判定手段と、
を有することを特徴とするプロダクト品質評価装置。
前記収束状況判定手段は、
前記バグ生起確率曲線から、
前記バグ生起確率曲線が残存バグ０件に収束しない；
試験が進行しているにも関わらず、前記バグ生起確率曲線値が増加、または、低下しない；
前記バグ生起確率曲線が残存バグ０件に収束；
のいずれかに分類し、品質達成状況として出力する手段を含む
請求項１記載のプロダクト品質評価装置。
前記品質状況評価手段は、
前記残存バグの収束状況に基づいて、
試験が足りないため、追加試験または強化試験が必要；
試験観点、試験実施方法に不備があるため、試験計画を見直す必要がある；
試験完了；
のいずれであるかを判定し、判定結果を前記品質達成状況として出力する手段を含む
請求項１記載のプロダクト品質評価装置。
前記品質総合判定手段は、
前記残存バグの件数、残存バグの収束率、前記残存バグの収束状況と、それぞれの閾値とを比較して、
試験が足りないため、追加試験または、強化試験が必要であるため、品質達成度は不十分；
試験観点、試験実施方法に不備があるため、試験計画を見直す必要があるため、品質達成度は不十分；
品質状況は良好なため、試験を終了；
のいずれであるかを判定する手段を含む
請求項１記載のプロダクト品質評価装置。
ソフトウェアの試験工程で検出されるバグの発生事象の動的挙動を確率モデルにより表現した信頼度成長モデルを用いてプロダクトの品質を評価するプロダクト品質評価方法あって、
バグ数推定手段、バグ生起確率曲線出力手段、収束状況判定手段、品質状況評価手段、品質総合判定手段を有する装置において、
前記バグ数推定手段が、バグ毎のバグ検出時間、バグ発見件数を取得し、最も適合度の高い信頼度成長モデルの平均値関数を用いて該バグ発見件数の累積件数から残存バグ件数を推定するバグ数推定ステップと、
前記バグ生起確率曲線出力手段が、前記平均値関数を１回微分することにより求められたバグ生起確率関数を用いてバグ生起確率を求め、該バグ生起確率を用いてバグ生起確率曲線を描画するバグ生起確率曲線出力ステップと、
前記収束状況判定手段が、前記バグ生起確率曲線から残存バグの収束状況を分類し、品質達成状況として出力する収束状況判定ステップと、
前記品質状況評価手段が、前記収束状況判定手段による前記残存バグの収束状況から品質達成状況を評価する品質状況評価ステップと、
前記品質総合判定手段が、前記残存バグの件数、残存バグの収束率及び前記残存バグの収束状況から総合評価を行う品質総合判定ステップと、
を行うことを特徴とするプロダクト品質評価方法。
前記収束状況判定ステップにおいて、
前記バグ生起確率曲線から、
前記バグ生起確率曲線が残存バグ０件に収束しない；
試験が進行しているにも関わらず、前記バグ生起確率曲線値が増加、または、低下しない；
前記バグ生起確率曲線が残存バグ０件に収束；
のいずれかに分類し、品質達成状況として出力する
請求項５記載のプロダクト品質評価方法。
前記品質状況評価ステップにおいて、
前記残存バグの収束状況に基づいて、
試験が足りないため、追加試験または強化試験が必要；
試験観点、試験実施方法に不備があるため、試験計画を見直す必要がある；
試験完了；
のいずれであるかを判定し、判定結果を前記品質達成状況として出力する
請求項５記載のプロダクト品質評価方法。
前記品質総合判定ステップにおいて、
前記残存バグの件数、残存バグの収束率、前記残存バグの収束状況と、それぞれの閾値とを比較して、
試験が足りないため、追加試験または、強化試験が必要であるため、品質達成度は不十分；
試験観点、試験実施方法に不備があるため、試験計画を見直す必要があるため、品質達成度は不十分；
品質状況は良好なため、試験を終了；
のいずれであるかを判定する
請求項５記載のプロダクト品質評価方法。