(57)【特許請求の範囲】
【請求項１】
新規に開発されたソフトウェアと過去に開発されたソフトウェアとの類似度をソースコードの類似性に基づき算出する算出手段と、
過去に開発されたソフトウェアのバグ密度を指標値とし、前記指標値に所定値を加算した上限値と減算した下限値とを算出し、前記類似度で補正して、ソフトウェアの開発規模に対するバグ密度を表したＵ管理図に記録する記録手段と、
記憶手段から前記Ｕ管理図を読み出して、新規に開発されたソフトウェアの開発規模に対応する補正後の上限値と下限値を求め、求めた２つの値に含まれる指標範囲を当該新規のソフトウェアに対する品質検査の許容範囲として出力する出力手段と、
を備えることを特徴とする品質基準算出装置。
【請求項２】
前記記録手段は、
前記所定値に対して前記類似度の逆数を乗算した値に前記指標値を加算した値を補正後の上限値とし、前記指標値から当該乗算した値を減算した値を補正後の下限値とすることを特徴とする請求項１に記載の品質基準算出装置。
【請求項３】
前記算出手段は、
新規に開発されたソフトウェアと過去に開発されたソフトウェアとの機能間の類似度を機能同士のソースコードの類似性に基づき算出することを特徴とする請求項１又は２に記載の品質基準算出装置。
【請求項４】
前記算出手段は、
前記機能間の類似度をユークリッド距離に基づき算出することを特徴とする請求項３に記載の品質基準算出装置。
【請求項５】
ソフトウェアは、複数の機能で構成され、
前記算出手段は、
各機能にそれぞれ対応する各ソースコードの構成値を機能間で正規化し、正規化後の構成値を用いて前記機能間の類似度を算出することを特徴とする請求項３又は４に記載の品質基準算出装置。
【請求項６】
前記ソースコードの構成値は、
少なくとも、ソースコードに関する、ファイル数、クラス数、メソッド数、宣言文と実行数の行数、コメント数、ソース総行数、最大ネスト数、複雑度、のうちいずれかであることを特徴とする請求項５に記載の品質基準算出装置。
【請求項７】
前記出力手段は、
新規に開発されたソフトウェアの開発難易度と過去に開発されたソフトウェアの開発難易度との比で、前記新規に開発されたソフトウェアの開発規模を補正することを特徴とする請求項１乃至６のいずれかに記載の品質基準算出装置。
【請求項８】
品質基準算出装置で行う品質基準算出方法において、
新規に開発されたソフトウェアと過去に開発されたソフトウェアとの類似度をソースコードの類似性に基づき算出するステップと、
過去に開発されたソフトウェアのバグ密度を指標値とし、前記指標値に所定値を加算した上限値と減算した下限値とを算出し、前記類似度で補正して、ソフトウェアの開発規模に対するバグ密度を表したＵ管理図に記録するステップと、
記憶手段から前記Ｕ管理図を読み出して、新規に開発されたソフトウェアの開発規模に対応する補正後の上限値と下限値を求め、求めた２つの値に含まれる指標範囲を当該新規のソフトウェアに対する品質検査の許容範囲として出力するステップと、
を備えることを特徴とする品質基準算出方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアの品質検査に用いる品質基準を算出する技術に関する。
【背景技術】
【０００２】
開発されたソフトウェアの品質を検査することは極めて重要であり、現在では、その品質基準を適切に決定・設定する技術が要求されている。ソフトウェアの品質基準としては、通常、開発規模やソースコードのステップ数に対するバグ数を示したバグ密度が用いられる。バグ密度をソフトウェア品質基準の指標値とし、その指標値の上限と下限を決定して、それらの限度内に含まれる指標範囲を管理限界範囲（＝品質検査の許容範囲）として予め設定しておく。そして、新たにソフトウェアが開発された場合、その新たなソフトウェアのバグ密度が管理限界範囲に収まるか否かに基づきソフトウェア品質の良し悪しが判定される。そのため、指標値及び管理限界範囲は、ソフトウェア品質の良否を決定する重要な要素であり、過去の開発実績又は品質検査者の経験に基づき慎重に決定・設定される（図５、特許文献１，２参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−２２５２２７号公報
【特許文献２】特開２０１２−１７３８２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、決定・設定される指標値及び管理限界範囲は、感覚的に決められることが多いため、その妥当性に懸念があった。具体的には、過去のソフトウェアとの類似度が低い場合、算出される管理限界範囲等の精度は低くなり、新規のソフトウェアに適した管理限界範囲等を設定できず、ソフトウェアの品質検査を適切に実施することができない（図６参照）。また、過去のソフトウェアに追加された一部の機能のみを変更したにもかかわらず、他の機能を含めて管理限界範囲等を決定した場合でも、同様に管理限界範囲等の精度は悪くなってしまう（図６参照）。
【０００５】
本発明は、上記事情を鑑みてなされたものであり、ソフトウェアの品質検査の許容範囲（＝管理限界範囲）を適正化することを目的とする。
【課題を解決するための手段】
【０００６】
以上の課題を解決するため、請求項１に記載の品質基準算出装置は、新規に開発されたソフトウェアと過去に開発されたソフトウェアとの類似度をソースコードの類似性に基づき算出する算出手段と、過去に開発されたソフトウェアのバグ密度を指標値とし、前記指標値に所定値を加算した上限値と減算した下限値とを算出し、前記類似度で補正して、ソフトウェアの開発規模に対するバグ密度を表したＵ管理図に記録する記録手段と、記憶手段から前記Ｕ管理図を読み出して、新規に開発されたソフトウェアの開発規模に対応する補正後の上限値と下限値を求め、求めた２つの値に含まれる指標範囲を当該新規のソフトウェアに対する品質検査の許容範囲として出力する出力手段と、を備えることを要旨とする。
【０００７】
本発明によれば、新規に開発されたソフトウェアと過去に開発されたソフトウェアとの類似度をソースコードの類似性に基づき算出し、過去に開発されたソフトウェアのバグ密度を指標値とし、その指標値に所定値を加算した上限値と減算した下限値とを算出し、その上限値と下限値を上記類似度（＝ソースコードの類似性に基づく類似度）で補正するため、ソフトウェアの品質検査の許容範囲（＝上限値と下限値との間に含まれる指標範囲）を適正化することができる。
【０００８】
請求項２に記載の品質基準算出装置は、請求項１に記載の品質基準算出装置において、前記記録手段は、前記所定値に対して前記類似度の逆数を乗算した値に前記指標値を加算した値を補正後の上限値とし、前記指標値から当該乗算した値を減算した値を補正後の下限値とすることを要旨とする。
【０００９】
請求項３に記載の品質基準算出装置は、請求項１又は２に記載の品質基準算出装置において、前記算出手段は、新規に開発されたソフトウェアと過去に開発されたソフトウェアとの機能間の類似度を機能同士のソースコードの類似性に基づき算出することを要旨とする。
【００１０】
請求項４に記載の品質基準算出装置は、請求項３に記載の品質基準算出装置において、前記算出手段は、前記機能間の類似度をユークリッド距離に基づき算出することを要旨とする。
【００１１】
請求項５に記載の品質基準算出装置は、請求項３又は４に記載の品質基準算出装置において、ソフトウェアは、複数の機能で構成され、前記算出手段は、各機能にそれぞれ対応する各ソースコードの構成値を機能間で正規化し、正規化後の構成値を用いて前記機能間の類似度を算出することを要旨とする。
【００１２】
請求項６に記載の品質基準算出装置は、請求項５に記載の品質基準算出装置において、前記ソースコードの構成値は、少なくとも、ソースコードに関する、ファイル数、クラス数、メソッド数、宣言文と実行数の行数、コメント数、ソース総行数、最大ネスト数、複雑度、のうちいずれかであることを要旨とする。
【００１３】
請求項７に記載の品質基準算出装置は、請求項１乃至６のいずれかに記載の品質基準算出装置において、前記出力手段は、新規に開発されたソフトウェアの開発難易度と過去に開発されたソフトウェアの開発難易度との比で、前記新規に開発されたソフトウェアの開発規模を補正することを要旨とする。
【００１４】
請求項８に記載の品質基準算出方法は、品質基準算出装置で行う品質基準算出方法において、新規に開発されたソフトウェアと過去に開発されたソフトウェアとの類似度をソースコードの類似性に基づき算出するステップと、過去に開発されたソフトウェアのバグ密度を指標値とし、前記指標値に所定値を加算した上限値と減算した下限値とを算出し、前記類似度で補正して、ソフトウェアの開発規模に対するバグ密度を表したＵ管理図に記録するステップと、記憶手段から前記Ｕ管理図を読み出して、新規に開発されたソフトウェアの開発規模に対応する補正後の上限値と下限値を求め、求めた２つの値に含まれる指標範囲を当該新規のソフトウェアに対する品質検査の許容範囲として出力するステップと、を備えることを要旨とする。
【発明の効果】
【００１５】
本発明によれば、ソフトウェアの品質検査の許容範囲（＝管理限界範囲）を適正化することができる。
【図面の簡単な説明】
【００１６】
【図１】品質基準算出装置の機能ブロック構成を示す図である。
【図２】品質基準算出装置の動作を示す図である。
【図３】開発機能に関するファイル数等のデータセット例を示す図である。
【図４】基礎Ｕ管理図の生成例を示す図である。
【図５】指標値及び管理限界範囲の設定例を示す図である。
【図６】従来技術の課題を説明する際の参照図である。
【発明を実施するための形態】
【００１７】
以下、本発明を実施する一実施の形態について図面を用いて説明する。
【００１８】
図１は、本実施の形態に係る品質基準算出装置１の機能ブロック構成を示す図である。品質基準算出装置１は、過去開発データ記憶部１１と、新規開発データ記憶部１２と、開発機能類似度算出部１３と、基礎Ｕ管理図生成部１４と、過去開発難易度算出部１５と、新規開発難易度算出部１６と、開発規模補正部１７と、指標値・管理限界範囲算出部１８と、を備えて構成される。
【００１９】
過去開発データ記憶部１１は、過去に開発された各ソフトウェアに関する分析実績データ及びプログラム関連データを記憶しておく。具体的には、過去に開発された各ソフトウェアについて、（１）開発規模（設計行数等）、バグ数、（２）工数（人月）、開発時間（月）、機能総量（ＦＰ（Function Point）、機能総数等）、ソフトウェア開発者の開発スキルレベル、（３）各機能のソースコードに係るファイル数、クラス数等、をそれぞれ記憶する。
【００２０】
新規開発データ記憶部１２は、新規に開発されたソフトウェアに関する分析実績データ及びプログラム関連データを記憶しておく。具体的には、新規に開発されたソフトウェアについて、（１）開発規模、（２）工数、開発時間、機能総量、ソフトウェア開発者の開発スキルレベル、（３）各機能のソースコードに係るファイル数、クラス数等、をそれぞれ記憶する。
【００２１】
開発機能類似度算出部１３は、過去及び新規に開発された各ソフトウェアに関する各機能のソースコードに係るファイル数、クラス数等を用いて、新規に開発されたソフトウェアと過去に開発されたソフトウェアとのソフトウェア間・機能間の類似度をソースコードの類似性に基づき算出する。
【００２２】
基礎Ｕ管理図生成部１４は、過去に開発されたソフトウェアのバグ密度を指標値とし、過去に開発された各ソフトウェアの開発規模、バグ数を用いて基礎指標値（＝バグ密度）及び基礎管理限界範囲（＝上限値・下限値）を算出し、その基礎管理限界範囲を上記類似度（＝ソースコードの類似性に基づく類似度）で補正した後に、ソフトウェアの開発規模に対するバグ密度を表したＵ管理図に描画して基礎Ｕ管理図としてメモリに記憶する。
【００２３】
過去開発難易度算出部１５は、過去に開発されたソフトウェアに関する工数、開発時間、機能総量、開発スキルレベルを用いて、過去のソフトウェアの開発難易度を算出する。
【００２４】
新規開発難易度算出部１６は、新規に開発されたソフトウェアに関する工数、開発時間、機能総量、開発スキルレベルを用いて、新規のソフトウェアの開発難易度を算出する。
【００２５】
開発規模補正部１７は、過去のソフトウェアの開発難易度と新規のソフトウェアの開発難易度との比で、新規に開発されたソフトウェアの開発規模を補正する。
【００２６】
指標値・管理限界範囲算出部１８は、メモリから基礎Ｕ管理図を読み出して補正後の基礎管理限界範囲を参照し、新規のソフトウェアに係る補正後の開発規模に対応する補正後の基礎管理限界範囲（＝補正後の上限値・補正後の下限値）を求め、求めた基礎管理限界範囲に含まれる指標範囲を新規のソフトウェアに対する品質検査の許容範囲として出力する。
【００２７】
ここまでが品質基準算出装置１の機能である。なお、この品質基準算出装置１は、ＣＰＵ及びメモリ等を備えたコンピュータで実現可能である。また、品質基準算出装置１としてコンピュータを機能させるための品質基準算出プログラム、その品質基準算出プログラムの記憶媒体を作成することも可能である。
【００２８】
次に、図１及び図２を参照しながら、品質基準算出装置１の動作について説明する。図２は、品質基準算出装置１の処理フローを示す図である。
【００２９】
まず、開発機能類似度算出部１３が、開発機能のソースコードに係るファイル数、クラス数等を用いて、新規開発機能と過去開発機能との類似度を開発機能同士のソースコードの類似性に基づき算出する（ステップＳ１）。
【００３０】
例えば、新規開発ソフトウェアと過去開発ソフトウェアについて、各開発機能のソースコードに係るファイル数等が図３（ａ）の場合、開発機能をＦ、ファイル数等のメトリクスをＭ、開発機能ＦｉにおけるメトリクスＭｊの実データ（＝ソースコードの構成値）をＶｉ，ｊとする（図３（ｂ）参照）。
【００３１】
そして、まず、実データＶｉ，ｊを開発機能Ｆｉ間で正規化する（ステップＳ１−１）。この正規化は、データセットに記録されている実データＶｉ，ｊはメトリクスＭｊによって値域が大きく異なるので、予測を与える影響を各メトリクスＭｊで均等にするために行う。具体的には、メトリクスＭｊが最大値の実データをｍａｘ（Ｖｊ）、最小値の実データをｍｉｎ（Ｖｊ）としたとき、式（１）を用いて正規化後の実データＶ’ｉ，ｊを計算する。なお、この正規化は、新規開発機能と過去開発機能の両方について行う。
【００３２】
【数１】
0006339989.tif 000002
続いて、新規開発機能と過去開発機能との類似度を計算する（ステップＳ１−２）。例えば、ユークリッド距離に基づき開発機能間の類似度を計算する。具体的には、新規開発機能をＦａ、過去開発機能をＦｉ、ユークリッド距離をｄｉｓｔ、新規開発機能Ｆａと過去開発機能Ｆｉとの類似度をｓｉｍ（Ｆａ，Ｆｉ）としたとき、式（２）を用いて類似度を計算する。
【００３３】
【数２】
0006339989.tif 000003
式（２）ではユークリッド距離の逆数を類似度としているので、開発機能間の類似度はユークリッド距離が小さいほど大きくなる。この式（２）より、新規開発機能と過去開発機能との類似度がソースコードの類似性に基づき計算されることになる。なお、ｙはメトリクスＭｊの総数である。
【００３４】
そして、最後に、計算された開発機能間の類似度をソフトウェア間の類似度ｓｉｍ（Ｓａ，Ｓｉ）とする（ステップＳ１−３）。Ｓａは新規開発ソフトウェアであり、Ｓｉは過去開発ソフトウェアである。例えば、過去開発機能の数量が１つであれば、計算された開発機能間の類似度は１つになるので、それをそのままソフトウェア間の類似度とする。一方、過去開発機能の数量が複数の場合、例えば、類似度の平均値をソフトウェア間の類似度とする。
【００３５】
次に、ステップＳ１の後、基礎Ｕ管理図生成部１４が、過去開発時の開発規模及びバグ数と、ステップＳ１で求めたソフトウェア間・開発機能間の類似度とを用いて基礎指標値及び基礎管理限界範囲（＝上限値・下限値）を算出し、基礎Ｕ管理図を生成する（ステップＳ２）。
【００３６】
具体的には、過去開発時の開発規模をｎ、過去開発時のバグ数をｃ、基礎指標値をｕ（ｕの上に“−”）、基礎管理限界範囲をｕｌ（ｕの上に“−”）、係数をｋとしたとき、式（３）を用いて基礎指標値（＝バグ密度）を計算し、式（４）を用いて基礎管理限界範囲（＝上限値・下限値）を計算する（ステップＳ２−１）。
【００３７】
【数３】
0006339989.tif 000004
【００３８】
【数４】
0006339989.tif 000005
式（４）では、基礎指標値ｕに対して加算・減算される所定値（＝ｋ√（ｕ／ｎｉ））に対して、ステップＳ１で求めたソフトウェア間・開発機能間の類似度の逆数が乗算されている。これにより、基礎管理限界範囲（＝上限値・下限値）が該類似度（すなわち、ソースコードの類似性に基づく類似度）に基づき調整（補正）され、適正化されることになる（図４の補正Ａ参照）。
【００３９】
その後、補正後の基礎管理限界範囲（＝補正後の上限値・補正後の下限値）を、横軸を開発規模、縦軸をバグ密度とするＵ管理図上にプロットして基礎Ｕ管理図（図４参照）を生成する（ステップＳ２−２）。この基礎Ｕ管理図は、新規開発ソフトウェアに対する品質検査の許容範囲（＝管理限界範囲）を決定するために後に用いられる。
【００４０】
なお、ｋは、上限・下限の幅を決定するための係数であり、開発内容に応じて任意に設定する。また、過去の開発規模ｎとは、例えば設計桁数である。Ｕ管理図、指標値、管理限界の定義等については、日本工業規格のJIS Z9020-1：2011(ISO 7870-1：2007)（http://kikakurui.com/z9/Z9020-1-2011-01.html）、同規格のJIS Z9021:1998（http://kikakurui.com/z9/Z9021-1998-01.html）に詳しく説明されている。
【００４１】
次に、ステップＳ２の後、過去開発難易度算出部１５が、過去開発データ記憶部１１から過去開発ソフトウェアに係る工数、開発時間、機能総量、開発スキルレベルを取得し、式（５）を用いて過去開発ソフトウェアの過去開発難易度Ｄｂを算出する（ステップＳ３）。
【００４２】
【数５】
0006339989.tif 000006
なお、βは定数である。過去開発ソフトウェアが複数の場合、各過去開発ソフトウェアの開発難易度の平均値を過去開発ソフトウェアの開発難易度としてもよい。
【００４３】
次に、ステップＳ３の後又はステップＳ３と同時に、新規開発難易度算出部１６が、新規開発データ記憶部１２から新規開発ソフトウェアに係る工数、開発時間、機能総量、開発スキルレベルを取得し、式（６）を用いて新規開発ソフトウェアの新規開発難易度Ｄａを算出する（ステップＳ４）。
【００４４】
【数６】
0006339989.tif 000007
次に、ステップＳ３及びステップＳ４の後、開発規模補正部１７が、式（７）を用いて、過去開発難易度Ｄｂと新規開発難易度Ｄａの比で新規開発ソフトウェアの開発規模ｎａを補正する（ステップＳ５）。具体的には、新規開発ソフトウェアの開発規模ｎａに対して、新規開発難易度Ｄａを過去開発難易度Ｄｂで除した値を乗算し、その乗算結果を新規開発ソフトウェアの補正後の開発規模ｎ’ａとする。その際、比を計算するのに代えて差分を計算してもよい。
【００４５】
【数７】
0006339989.tif 000008
式（７）より、新規開発ソフトウェアの開発規模ｎａに対して過去開発難易度Ｄｂと新規開発難易度Ｄａの比を乗算するので、新規開発ソフトウェアの開発規模ｎａは、過去開発と新規開発の両方の開発難易度に基づき調整（補正）され、適正化されることになる（図４の補正Ｂ参照）。
【００４６】
最後に、ステップＳ５の後、指標値・管理限界算出部１８が、ステップＳ２で生成していた図４の基礎Ｕ管理図をメモリから取得し、新規開発ソフトウェアの補正後の開発規模ｎ’ａに対応する基礎管理限界範囲（＝補正後の上限値・補正後の下限値）を求め、求めた基礎管理限界範囲に含まれる指標範囲を新規のソフトウェアに対する品質検査の許容範囲として出力する（ステップＳ６）。
【００４７】
以上より、本実施の形態によれば、開発機能類似度算出部１３が、新規に開発されたソフトウェアと過去に開発されたソフトウェアとの類似度をソースコードの類似性に基づき算出し、基礎Ｕ管理図生成部１４が、過去に開発されたソフトウェアのバグ密度を指標値とし、その指標値に所定値を加算した上限値と減算した下限値とを算出し、その上限値と下限値を上記類似度（＝ソースコードの類似性に基づく類似度）で補正するので、ソフトウェアの品質検査の許容範囲（＝上限値と下限値との間に含まれる指標範囲）を適正化することができる。
【００４８】
また、本実施の形態によれば、開発規模補正部１７が、新規に開発されたソフトウェアの開発難易度と過去に開発されたソフトウェアの開発難易度との比で、新規に開発されたソフトウェアの開発規模を補正するので、該新規のソフトウェアの開発規模を適正化することができる。
【００４９】
最後に、図３（ａ）のデータセットは、あくまでも一例である。他のメトリクスを用いてもよい。また、図３（ａ）の場合、少なくとも、ソースコードに関する、ファイル数、クラス数、メソッド数、宣言文と実行数の行数、コメント数、ソース総行数、最大ネスト数、複雑度、のうちいずれかを用いればよい。
【００５０】
なお、Ｕ管理図とは、バグ密度をソフトウェアの開発規模に応じて管理するための管理図である。ソフトウェア管理の場合、一般的には、バグ密度の平均値や指標値に対して管理限界から外れる確率が約０．３％（＝係数ｋ）であるという考え方で作成される。
【符号の説明】
【００５１】
１…品質基準算出装置
１１…過去開発データ記憶部
１２…新規開発データ記憶部
１３…開発機能類似度算出部（算出手段）
１４…基礎Ｕ管理図生成部（記録手段）
１５…過去開発難易度算出部
１６…新規開発難易度算出部
１７…開発規模補正部
１８…指標値・管理限界範囲算出部（出力手段）
Ｓ１〜Ｓ６…ステップ
【図１】
0006339989.tif 000009
【図２】
0006339989.tif 000010
【図３】
0006339989.tif 000011
【図４】
0006339989.tif 000012
【図５】
0006339989.tif 000013
【図６】
0006339989.tif 000014