(57)【要約】【課題】  ソフトウェアの構造的な障害の発生箇所を予測することができる危険度判定プログラムを提供する。【解決手段】  ソフトウェアを解析して、ソフトウェア内のプログラムの実行とプログラムが扱うデータによる影響がソフトウェア内の他のプログラムや他のデータに波及していくモデルを、プログラムとデータの依存関係に基づいて求めるソフトウェアモデル構築部１２と、ソフトウェアモデルを利用して、ソフトウェアが使用するＡＰＩの使用によって、ソフトウェアにおいて過去に発生した障害の発生箇所が受ける影響の度合いを求める波及行列計算部１３と、影響の度合いを使用して、ＡＰＩの使用が障害発生の遠因となった確率を推定し、ＡＰＩの使用による危険度として求めるＡＰＩ危険度計算部１４とを有している。【選択図】        図２
2010257091.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータを、
ソフトウェアを解析して、前記ソフトウェア内のプログラムの実行と該プログラムが扱うデータによる影響が前記ソフトウェア内の他のプログラムや他のデータに波及していくモデルを、プログラムとデータの依存関係に基づいて求めるモデル構築手段と、
前記モデルを利用して、前記ソフトウェアが使用するＡＰＩの使用によって、前記ソフトウェアにおいて過去に発生した障害の発生箇所が受ける影響の度合いを求める影響度合い算出手段と、
前記影響の度合いを使用して、前記ＡＰＩの使用が障害発生の遠因となった確率を推定し、前記ＡＰＩの使用による危険度として求める推定手段と
して機能させる危険度判定プログラム。
【請求項２】
前記モデル構築手段は、前記モデルを、前記ソフトウェア内で使用されるデータの依存関係や、前記プログラムの制御依存関係に基づくグラフ構造で構築する、請求項１記載の危険度判定プログラム。
【請求項３】
前記推定手段は、最尤推定法を用いて前記ＡＰＩの使用が障害発生の遠因となった確率を推定する、請求項１又は２記載の危険度判定プログラム。
【請求項４】
前記推定手段は、前記ＡＰＩの使用によって障害の発生箇所が受ける影響度合いを、該障害の発生箇所が前記ＡＰＩに及ぼす影響度合いとして使用し、前記ソフトウェアで過去に発生した障害の発生箇所の影響度合いを加算して前記ソフトウェアが使用する前記ＡＰＩの危険度を算出する、請求項１又は２記載の危険度判定プログラム。
【請求項５】
ソフトウェア又は該ソフトウェアの一部分で使用しているＡＰＩの危険度を前記各手段を使用して算出し、算出した各ＡＰＩの危険度に基づいて前記ソフトウェア又は該ソフトウェアの一部分に含まれる危険度を算出する算出手段と、
前記算出手段で算出された危険度に応じて前記ソフトウェア又は該ソフトウェアの一部分の開発工数を補正する補正手段とを有する、請求項１から４のいずれか一項記載の危険度判定プログラム。
【請求項６】
ソフトウェアを解析して、前記ソフトウェア内のプログラムの実行と該プログラムが扱うデータによる影響が前記ソフトウェア内の他のプログラムや他のデータに波及していくモデルを、プログラムとデータの依存関係に基づいて求めるモデル構築手段と、
前記モデルを利用して、前記ソフトウェアが使用するＡＰＩの使用によって、前記ソフトウェアにおいて過去に発生した障害の発生箇所が受ける影響の度合いを求める影響度合い算出手段と、
前記影響の度合いを使用して、前記ＡＰＩの使用が障害発生の遠因となった確率を推定し、前記ＡＰＩの使用による危険度として求める推定手段と、
を有する危険度判定装置。
【請求項７】
危険度判定装置によって実行される危険度判定方法であって、
ソフトウェアを解析して、前記ソフトウェア内のプログラムの実行と該プログラムが扱うデータによる影響が前記ソフトウェア内の他のプログラムや他のデータに波及していくモデルを、プログラムとデータの依存関係に基づいて求めるステップと、
前記モデルを利用して、前記ソフトウェアが使用するＡＰＩの使用によって、前記ソフトウェアにおいて過去に発生した障害の発生箇所が受ける影響の度合いを求めるステップと、
前記影響の度合いを使用して、前記ＡＰＩの使用が障害発生の遠因となった確率を推定し、前記ＡＰＩの使用による危険度として求めるステップと、
を有する危険度判定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、危険度判定プログラム、危険度判定装置及び方法に関する。特に、本発明は、ソフトウェア開発において、開発作業の効率化、リスク低減や品質向上を図る技術に関する。
【背景技術】
【０００２】
ソフトウェア開発において、潜在的に障害が入りやすい箇所や、作業の難易度の高い箇所を評価する技術が提案されている。例えば、特許文献１では、開発されたアプリケーションがＡＰＩ（Application Program Interface）を正しく使用しているか否かをアプリケーションから渡されたＡＰＩの使用方法に関する情報を使用して検査する装置が提案されている。また、特許文献２には、ソフトウェアシステムの試験のための効率的な試験項目の設計を支援するシステムが提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−３３４５４１号公報
【特許文献２】特開２００１−３３７８４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
障害の原因には様々なものがある。特に問題なのがソフトウェア内部の様々な箇所が複雑に絡み合って相互作用を起こして発生する障害である。この障害は、障害が発生した箇所と、障害発生の原因となった箇所が常に同じとは限らず、また原因となる箇所が複数ある場合も多い。例えば、あるＡＰＩが原因となって発生する障害の発生箇所は、このＡＰＩを使用した箇所にだけ出現するとは限らない。このような障害を以下ではソフトウェアの構造的な障害と呼ぶ。このようなソフトウェアの構造的な障害が発生する危険度の高い箇所を予測することができれば、開発作業の効率化、リスク低減や品質向上に役立つ。特許文献１及び２にもＡＰＩの使用により発生するソフトウェアの構造的な障害の発生箇所を予測する技術の開示はない。
【０００５】
本発明は上記事情に鑑みてなされたものであり、ソフトウェアの構造的な障害の発生箇所を予測することができる危険度判定プログラム、危険度判定装置及び方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本明細書に開示の危険度判定プログラムは、コンピュータを、ソフトウェアを解析して、前記ソフトウェア内のプログラムの実行と該プログラムが扱うデータによる影響が前記ソフトウェア内の他のプログラムや他のデータに波及していくモデルを、プログラムとデータの依存関係に基づいて求めるモデル構築手段と、前記モデルを利用して、前記ソフトウェアが使用するＡＰＩの使用によって、前記ソフトウェアにおいて過去に発生した障害の発生箇所が受ける影響の度合いを求める影響度合い算出手段と、前記影響の度合いを使用して、前記ＡＰＩの使用が障害発生の遠因となった確率を推定し、前記ＡＰＩの使用による危険度として求める推定手段として機能させることを特徴としている。
【発明の効果】
【０００７】
本明細書に開示の危険度判定プログラムによれば、ソフトウェアの構造的な障害の発生箇所を予測することができる。
【図面の簡単な説明】
【０００８】
【図１】危険度判定装置の構成の一例を示す図である。
【図２】制御部に実現される機能ブロックの構成の一例を示す図である。
【図３】ソースコード解析部の構成の一例を示すブロック図である。
【図４】コードエンティティ及びデータエンティティの構成の一例を示す図である。
【図５】関係の構成の一例を示す図である。
【図６】ソースコードの一例を示す図である。
【図７】コードエンティティのリストの一例を示す図である。
【図８】データエンティティのリストの一例を示す図である。
【図９】関係のリストの一例を示す図である。
【図１０】ソフトウェアモデル構築部の構成の一例を示す図である。
【図１１】ソフトウェアモデルの一例を示す図である。
【図１２】波及行列計算部の構成の一例を示す図である。
【図１３】影響波及モデルの一例を示す図である。
【図１４】影響波及関係の構成の一例を示す図である。
【図１５】ＡＰＩリストの一例を示す図である。
【図１６】発生した障害履歴の一例を示す図である。
【図１７】波及行列の一例を示す図である。
【図１８】ＡＰＩ危険度計算部の構成の一例を示す図である。
【図１９】ＡＰＩ危険度の一例を示す図である。
【図２０】制御部の処理手順を示すフローチャートである。
【図２１】実施例３の処理概要を示す図である。
【図２２】実施例３の危険度判定装置の構成の一例を示す図である。
【図２３】工数補正テーブルの一例を示す図である。
【発明を実施するための形態】
【０００９】
以下、添付図面を参照しながら本発明の好適な実施例を説明する。
【実施例１】
【００１０】
図１に、本発明を適用した危険度判定装置１の構成を示す。
危険度判定装置１は、制御部２と、記憶装置６と、操作部８と、入力インタフェース７と、表示部１０と、グラフィックインタフェース９とを備えている。また、制御部２は、ＣＰＵ（Central Processing Unit）３と、ＲＯＭ（Read Only Memory）４と、ＲＡＭ（Read Only Memory）５とを備えている。
【００１１】
まず、制御部２について説明する。ＲＯＭ４には、ＣＰＵ３が制御に使用するプログラムが記録されている。ＣＰＵ３は、ＲＯＭ４に記録されたプログラムを読み込んで、読み込んだプログラムに従った制御を行う。ＲＡＭ５には、ＣＰＵ３が演算に使用するデータや、演算結果のデータが記録される。ＣＰＵ３、ＲＡＭ５などのハードウェアと、ＲＯＭ４に格納されたプログラムとの協働によって実現される制御部２の機能ブロックについては後ほど説明する。
【００１２】
記憶装置６には、制御部２が制御に使用するデータが格納される。制御部２の制御によって記憶装置６内には後述するデータベース（以下、データベースをＤＢと略記する場合もある）が構築され、制御部２の制御によってデータベースとして記憶装置６内に記憶されたデータが取り出し可能となる。データベースには、ソースコードＤＢ１５、ＡＰＩリストＤＢ１６、サンプルソフトウェアの障害履歴ＤＢ１７、ＡＰＩ危険度ＤＢ１８、データエンティティリストＤＢ１９、コードエンティティリストＤＢ２０、関係リストＤＢ２１、ソフトウェアモデルＤＢ２２、影響波及モデルＤＢ２３、波及行列ＤＢ２４等が含まれる。これらのデータベースの詳細については後述する。
【００１３】
操作部８は、ユーザの操作入力を受け付ける受付部であり、操作部８によって受け付けられた入力情報は、入力インタフェース７を介して制御部２に出力される。ユーザは、例えば、操作部８を使用してソフトウェア開発に使用するＡＰＩの設定等を入力する。
【００１４】
表示部１０には、制御部２の判定結果がグラフィックインタフェース９を介して表示される。例えばリスクポイントの算出結果や、リスクポイントに基づいて補正した工数の見積もり等が表示される（これらの詳細については、後述する）。
【００１５】
次に、ＣＰＵ３、ＲＡＭ４等のハードウェアと、ＲＯＭ４に記録されたプログラムとの協働によって実現される制御部２の機能ブロックについて、図２を参照しながら説明する。
制御部２は、ソースコード解析部１１と、ソフトウェアモデル構築部１２と、波及行列計算部１３と、ＡＰＩ危険度計算部１４とを実行可能な機能ブロックとして備えている。
制御部２は、過去に作成したソフトウェア（以後、サンプルソフトウェアと呼ぶ）からプログラムを入力する。なお、プログラムには、コンピュータが実際に処理命令に従って処理を行う、機械語翻訳されたプログラムだけではなく、機械語に翻訳されていないソースコードも含まれる。以下では、プログラムとしてソースコードを入力した場合を例に説明する。また、制御部２は、各サンプルソフトウェアで使用されているＡＰＩのリスト（以下、ＡＰＩリストと呼ぶ）と、各サンプルソフトウェアで発生した障害のリスト（以後、障害履歴と呼ぶ）とを入力する。制御部２は、これらの情報を入力して、図２に示す各機能ブロックで後述する処理を施すことにより、各ＡＰＩのＡＰＩ危険度を算出する。算出したＡＰＩ危険度は、ＡＰＩ危険度ＤＢ１８に記憶される。
【００１６】
各機能ブロックについて説明する。
ソースコード解析部１１は、ＡＰＩ危険度の算出を行うためのサンプルソフトウェアのソースコードを入力とし、静的解析などにより制御依存情報やデータ依存情報などの情報の抽出を行う。
【００１７】
ソフトウェアモデル構築部１２は、ソースコード解析部１１で抽出した情報を用い、サンプルソフトウェアのモデル（以後、ソフトウェアモデルと呼ぶ）を構築する。
【００１８】
波及行列計算部１３は、ソフトウェアモデル構築部１２で構築したソフトウェアモデルと、危険度の判定を行う対象のＡＰＩリストと、サンプルソフトウェアの障害履歴を入力する。波及行列計算部１３は、入力した情報に基づいて影響波及モデルを構築する。また、波及行列計算部１３は、構築した影響波及モデルに基づいてＡＰＩと障害発生箇所との関係を表す波及行列を計算する。
【００１９】
ＡＰＩ危険度計算部１４は、波及行列とサンプルソフトウェアの障害履歴から、ＡＰＩの危険度を求める。
【００２０】
次に、図３を参照しながらソースコード解析部１１の詳細について説明する。いて詳細に述べる。図３はソースコード解析部１１の構成図である。ソースコード解析部１１は、構文解析部１１１とモデル要素抽出部１１２とを備えている。
【００２１】
構文解析部１１１は、外部からサンプルソフトウェアのソースコードを入力し、構文解析を行って構文解析情報を得る。構文解析部１１１は、ソースコードを解析して、構文情報を出力する。構文解析部１１１には、コンパイラなどで利用されている既存技術を用いる。
【００２２】
モデル要素抽出部１１２は、構文解析部１１１から出力される構文解析情報を入力して、後述のソフトウェアモデルを構成する各要素である、コードエンティティ、データエンティティ、「関係」のリストを抽出する。
コードエンティティは、ソースコードのある一部分に該当する。「ソースコードの一部分」の粒度としては、ソースファイル、クラス、メソッド（または関数、サブルーチン）、またはブロックなどの多様な範囲を取り得る。
ＡＰＩとは、ライブラリやフレームワークがアプリケーションソフトウェアのために提供する公開されたインタフェースである。多くの場合、メソッド（または関数、サブルーチン）の呼び出しとなる。ＡＰＩはコードエンティティである。
データエンティティは、ソフトウェアが扱うデータを示す。データベース、ファイル、フィールドまたは変数の多様な範囲を取り得る。以下では、コードエンティティとデータエンティティをまとめて単にエンティティと呼ぶ。
【００２３】
あるエンティティとあるエンティティの間には何らかの関係がある場合がある。そのとき、「関係」とは、どのエンティティとどのエンティティの間にどんな種類の関係があるかを示す。
図４にコードエンティティの構造の一例を示す。エンティティ名とエンティティタイプの二項目からなる。エンティティ名は、ソフトウェア全体でこのコードエンティティの指す範囲を一意に特定できる情報である。エンティティタイプはこのコードエンティティの種類を保持する。
また、データエンティティの構造も図４に示す通りであり、エンティティ名とエンティティタイプの二項目からなる。エンティティ名は、ソフトウェア全体でこのデータエンティティの指す範囲を一意に特定できる情報である。エンティティタイプはこのデータエンティティの種類を保持する。
【００２４】
図５に「関係」の構造の一例を示す。始点エンティティ名と終点エンティティ名と関係タイプの三項目からなる。始点エンティティ名と終点エンティティ名はある関係を持つ二つのエンティティのエンティティ名である。関係タイプはその関係の種類を保持する。「ＡはＢに対してＸという関係を持つ」という場合、始点エンティティ名はＡ、終点エンティティ名はＢ、関係タイプはＸとなる。このＡとＢを入れ替えると意味が変わってしまう場合、始点エンティティ名と終点エンティティ名の順序は本質的に重要である。
また、「ＣとＤはＹという関係を持つ」という場合、始点エンティティ名はＣ、終点エンティティ名はＤ、関係タイプはＹとなる。このＣとＤを入れ替えても意味が変わらない場合、始点エンティティ名と終点エンティティ名の順序は本質的ではなく可換である。関係タイプごとに可換か否かは自ずと決まっている。
【００２５】
図６はあるソフトウェアのソースコードの一部である。なお、本実施例の動作の説明に不要な部分は省略し簡略化している。また、行頭には説明の便を図るために４桁の行番号を付している。
構文解析部１１１は、図６に示すソースコードを解析し、字句要素を切り分け、構文的な意味づけを判別し、判別結果として解析情報をモデル要素抽出部１１２に出力する。モデル要素抽出部１１２は、解析情報に基づいてコードエンティティとデータエンティティに該当するものを抽出する。また、モデル要素抽出部１１２は、予め定義された「関係」に該当する構文構造を「関係」として抽出する。ここでは、「関係」の種類として「呼び出し関係」、「リード関係」、「ライト関係」の３つが定義されているものとする。ただし、このほかにも「委譲関係」など３種類を超えて関係の種類を増やすことが可能である。
【００２６】
図７に、図６のソースコードから抽出されたコードエンティティのリストを示す。同様に、図８にデータエンティティのリスト、図９に「関係」のリストを示す。
図６にはコードエンティティがＡ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，ＡＰＩ１,ＡＰＩ２の８つ存在し、データエンティティがＱの１つ存在する。図６の０４００行から０４２０行までは関数Ｃであり、０４１０行で関数ＡＰＩ１が呼ばれている。そのため、コードエンティティＣがコードエンティティＡＰＩ１を「呼び出し」ているという「関係」がある。また、同じく０４１０行では、変数Ｑに代入が行われている。そのため、コードエンティティＣがデータエンティティＱに「ライト」しているという「関係」がある。
【００２７】
次に、ソフトウェアモデル構築部１２について詳細に説明する。図１０はソフトウェアモデル構築部１２の構成図である。
ソフトウェアモデル構築部１２は、コードエンティティ、データエンティティ、「関係」のリストを入力し、ソフトウェアモデルを構築する。ソフトウェアモデル構築部１２は、構築したソフトウェアモデルをソフトウェアモデルＤＢ２２に記憶させる。図１１に、ソフトウェアモデルの一例を示す。ソフトウェアモデル構築部１２は、図７に示すコードエンティティのリスト、図８に示すデータエンティティのリスト、図９に示す「関係」のリストを参照して、図１１に示すソフトウェアモデルを構築する。ソフトウェアモデルは有向グラフで表現される。グラフの頂点はコードエンティティまたはデータエンティティであり、グラフの有向辺は関係である。ソフトウェアモデル構築部１２は、入力されたリストからこのソフトウェアモデルを構築し、ソフトウェアモデルＤＢ２２に記憶させる。
【００２８】
次に、波及行列計算部１３について詳細に説明する。図１２に、波及行列計算部１３の構成を示す。波及行列計算部１３は、影響波及モデル構築部１３１と波及行列構築部１３２とを備えている。
影響波及モデル構築部１３１は、ソフトウェアモデル構築部１２から、ソフトウェアモデルを入力し、後述する手続きに従って影響波及モデルを構築する。
波及行列構築部１３２は、構築された影響波及モデルを影響波及モデル構築部１３１から受け取る。また、波及行列構築部１３２は、外部からＡＰＩリストと、サンプルソフトウェアで発生した障害のリスト（障害履歴）とを入力する。波及行列構築部１３２は、入力したこれらの情報から、後述する手続きに従って波及行列を構築して出力する。
【００２９】
影響波及モデル構築部１３１が影響波及モデルを構築する処理について説明する。
図１３に、影響波及モデルの一例を示す。この影響波及モデルは、図１１のソフトウェアモデルをもとに構築されたものである。影響波及モデルはソフトウェアモデルと同様にグラフ構造を取る。頂点はソフトウェアモデルのエンティティと同じものであり、ソフトウェアモデルに含まれるエンティティ全体か、又はその一部が影響波及モデルに含まれる。有向辺はソフトウェアモデルの「関係」とは異なり、影響波及関係と呼ばれ、図１４に示す構造を持つ。影響波及関係において、始点エンティティは「関係」の始点エンティティと同じものである。同様に終点エンティティは「関係」の終点エンティティと同じものである。減衰係数は、始点エンティティから終点エンティティへの影響波及において、影響波及がどれだけ衰えるかを示す乗数である。図１３には、減衰係数を有向辺に付して示している。ソフトウェアモデルに含まれる「関係」全体か、又はその一部に対応する（＝始点エンティティと終点エンティティを同じくする）影響波及関係が影響波及モデルに含まれる。ただし、場合によっては、影響波及関係では始点と終点が反転したものに置き換わったり、始点と終点が反転したものが追加される場合がある。
【００３０】
ソフトウェアモデルのある「関係」について、予め変換ルールを用意する。
例えば、図１１から図１３への変換の場合には、以下のルール１、２、３が用意されており、影響波及モデル構築部１３１は、図１１のすべての「関係」についてルール１、２、３を適用して、図１３の影響波及モデルを構築する。なお、影響波及モデルではコードエンティティとデータエンティティを区別しないため、図１３に示す例でもこれら二種を区別していない。
【００３１】
（ルール１）
ルール１は、始点エンティティ名で指定されるエンティティのエンティティタイプが「関数」で、かつ、終点エンティティ名で指定されるエンティティのエンティティタイプが「関数」で、かつ、関係タイプが「呼び出し」の場合に適用される。この場合、始点エンティティ名に終点エンティティ名を持ち、終点エンティティ名に始点エンティティ名を持ち（つまり、向きが反転する）、減衰係数に０．５を持つ影響波及関係を生成する。
（ルール２）
ルール２は、始点エンティティ名で指定されるエンティティのエンティティタイプが「関数」で、かつ、終点エンティティ名で指定されるエンティティのエンティティタイプが「変数」で、かつ、関係タイプが「リード」の場合に適用される。この場合、始点エンティティ名に終点エンティティ名を持ち、終点エンティティ名に始点エンティティ名を持ち（つまり、向きが反転する）、減衰係数に０．１を持つ影響波及関係を生成する。
（ルール３）
ルール３は、始点エンティティ名で指定されるエンティティのエンティティタイプが「関数」で、かつ、終点エンティティ名で指定されるエンティティのエンティティタイプが「変数」で、かつ、関係タイプが「ライト」である場合に適用される。この場合、始点エンティティ名に始点エンティティ名を持ち、終点エンティティ名に終点エンティティ名を持ち（つまり、向きはそのまま）、減衰係数に０．５を持つ影響波及関係を生成する。
このようなルールに従って、影響波及モデル構築部１３１では影響波及モデルを構築する。
【００３２】
次に、波及行列構築部１３２が波及行列を構築する処理について説明する。
ＡＰＩリストＤＢ１６から入力したＡＰＩリストは、ＡＰＩであるコードエンティティのエンティティ名のリストである。図１５にＡＰＩリストの例を示す。ソフトウェアの障害履歴は、過去に障害が発生した箇所を示すエンティティ名のリストである。図１６にソフトウェアの障害履歴の例を示す。
図１７に、図１３に示す影響波及モデル、図１５に示すＡＰＩリスト、図１６に示すソフトウェアの障害履歴に対応して構築された波及行列の例を示す。波及行列の行は各ＡＰＩを意味し、列は各エンティティを意味する。行の並び順、および列の並び順は任意であり、順序が変わっても構わない。
【００３３】
波及行列構築部１３２は、以下の手順で波及行列を構築する。
（１）各ＡＰＩについて、ＡＰＩを起点として以下の（２）、（３）、（４）の手順を繰り返す。
（２）各エンティティについて、エンティティを目標として（３）、（４）の手順を繰り返す
（３）起点となったＡＰＩエンティティから、影響波及モデル上でグラフ探索を行い、起点から目標のエンティティへの最短経路を求める。経路の距離を計算する際の有向辺ごとの距離は、さまざまに定めることができる。この例では「減衰係数の逆数の対数」を選ぶが、単純に定数1としてもよい。
（４）求められた最短経路に沿って、各有向辺の減衰係数をすべて掛け合わせたものを、波及行列の起点ＡＰＩの行と目標エンティティの列の交差する項の値とする。起点ＡＰＩから目標エンティティまでの経路が無い場合、該当する項の値は０とする。起点ＡＰＩと目標エンティティが同じ場合、該当する項の値は１とする。
【００３４】
例えば、図１７におけるＡＰＩ１の行とＤの列の項の値は０．０２５であるが、これは、図１３においてＡＰＩ１からＤまでの最短経路がＡＰＩ１→Ｃ→Ｑ→Ｄであるから、各有向辺の減衰係数を乗じて０．５×０．５×０．１＝０．０２５ と求められる。この項の値のことを波及係数と呼ぶ。例えば、行がＡＰＩ１、列がＤの場合はＡＰＩ１からＤへの波及係数と呼ぶ。このようにして、波及行列構築部１３２では波及行列を構築する。
【００３５】
なお、上記の波及行列計算部１３の説明では、影響波及モデル構築部１３１と波及行列構築部１３２との二つのフェーズに分けて波及行列を計算する例を示したが、先に述べた変換ルールが複雑なものになると、ＡＰＩごとに影響波及モデルが別のものになる場合がある。そのような場合は、各ＡＰＩごとに影響波及モデルを構築して波及行列の行の各値を計算する必要があるため、影響波及モデル構築部１３１と波及行列構築部１３２とに分けずに一つのフェーズで構築するとよい。
【００３６】
次に、ＡＰＩ危険度計算部１４について詳細に説明する。図１８に、ＡＰＩ危険度計算部１４の構成を示す。ＡＰＩ危険度計算部１４は、波及行列とソフトウェアの障害履歴を入力し、ＡＰＩ危険度を計算する。ＡＰＩ危険度計算部１４は、計算したＡＰＩ危険度をＡＰＩ危険度ＤＢ１８に記憶させる。
【００３７】
ＡＰＩ危険度とは、ＡＰＩを使用したときの障害の起こり易さの度合いである。先に求めた波及行列は、各ＡＰＩから各エンティティへ直接または間接的に影響が波及していくことによる影響波及の程度の大きさを示している。あるＡＰＩを使用したときの障害の起こり易さが高ければ、このＡＰＩから受ける影響波及の程度が大きいエンティティでは障害が発生する可能性が高くなる。しかし、ＡＰＩを使用したときの障害の起こり易さを直接知ることはできないため、得られている情報から推定を行うほか無い。
【００３８】
推定の方法としては、ここでは最尤推定法を用いる。最尤推定法とは、「観測された事象は、発生確率が最も高い事象にちがいない」ということを根拠にする推定法である。この発生確率は尤度と呼ばれる。尤度は推定対象となる変数（この場合はＡＰＩを使用したときの障害の起こり易さ）をパラメータとして持つため尤度関数とも呼ばれる。尤度関数を最大化するパラメータを求めれば、そのパラメータが「最も尤もらしい」推定値となる。最尤推定法については、例えば、東京大学教養学部統計学教室編「自然科学の統計学」などに詳細が記載されている。
【００３９】
最尤推定法を用いた推定の具体的な手順について説明する。
まず、記号を以下の通り定義する。
ＡＰＩリストの中のＡＰＩの数をＮとする。ＡＰＩリスト中のｉ番目のＡＰＩをＡＰＩｉとする。当然、１≦ｉ≦Ｎである。ＡＰＩｉは波及行列の第ｉ行に対応する。
また、ソフトウェアのエンティティの数をＭとする。ｊ番目のエンティティをＸｊとする。当然、１≦ｊ≦Ｍである。Ｘｊは波及行列の第ｊ列に対応する。
また、ＡＰＩｉからＸｊへの波及係数をＥｉｊとする。Ｅｉｊは波及行列の各項に対応する。
また、エンティティＸｊで障害が発生したかどうかをＦｊで表す。Ｆｊ＝１なら障害が発生し、Ｆｊ＝０なら障害が発生していなかったことを意味する。この情報はソフトウェアの障害履歴から定まる。
また、ＡｉをＡＰＩｉを使用したときの障害の起こり易さの度合いとする。Ａｉは１未満０以上の範囲である。θをＡｉの集合、すなわち｛Ａ１，Ａ２，・・・ＡＮ｝とする。このθを推定することが目的である。
ここで、ＡＰＩｉを使用したことによってＸｊで障害が発生する確率はＥｉｊ・Ａｉで表せると仮定をおく。エンティティＸｊで障害が発生しない確率をＱ（Ｘｊ）と書くと、Ｑ（Ｘｊ）は、以下に示す式（１）となる。
【００４０】
【数１】
2010257091.tif 000003
【００４１】
また、エンティティＸｊで障害が発生する確率をＰ（Ｘｊ）と書くと、Ｐ（Ｘｊ）は、以下に示す式（２）となる。
【００４２】
【数２】
2010257091.tif 000004
【００４３】
また、入力したサンプルソフトウェアで障害（障害履歴）が発生する確率(尤度)を関数Ｌ（θ）とすると、尤度関数Ｌ（θ）は次の式（３）で表せる。
【００４４】
【数３】
2010257091.tif 000005
【００４５】
この式（３）を最大にするθを求めるには、適切な数値解法、例えばNelder-Mead法などを用いればよい。Nelder-Mead法については、J.A.Nelder and R.Mead "A simplex method for function minimization"Computer Journal, vol.7, pp.308-313 (1965)を参照のこと。
【００４６】
図１７の波及行列、図１６のソフトウェアの障害履歴の例から、実際に尤度関数を求める例を示す。ＡＰＩ１の障害の起こり易さの度合いをＡ１、ＡＰＩ２の障害の起こり易さの度合いをＡ２としてθ＝｛Ａ１，Ａ２｝とすると、尤度関数Ｌ（θ）は、以下に示す式（４）の通りになる。
【００４７】
【数４】
2010257091.tif 000006
【００４８】
このＬ（θ）を最大化するθをNelder-Mead法を用いて数値的に解くと、Ａ１＝０．６６９、Ａ２＝０．１１８が得られる。
ＡＰＩ危険度計算部１４は、この得られたθ＝｛Ａ１，Ａ２，・・・、ＡＮ｝をＡＰＩの危険度として出力する。図１９には、前述の例に従ったＡＰＩの危険度の出力の実例を示す。なお、ＡＰＩ危険度の値は相対値として意味があるが、絶対値としての意味は定義されない。すなわち、Ａ１とＡ２を比べてＡ１の方が大きい場合はＡ１の方が危険であるが、Ａ１の値が０．３だからといって、障害発生率やその期待値が常に０．３というわけではない。
【００４９】
図２０に示すフローチャートを参照しながら制御部２の処理手順を説明する。
まず、制御部２は、ＡＰＩ危険度を算出するためのサンプルソフトウェアのソースコードを入力し、静的解析によりソースコードの構文的な意味を解析する（ステップＳ１）。次に、制御部２は、解析結果に基づいて、コードエンティティ、データエンティティに該当するものを抽出し、さらに、予め定義された関係を満たす構文構造を抽出する（ステップＳ２）。制御部２は、抽出したデータエンティティをデータエンティティリストＤＢ１９に、コードエンティティをコードエンティティリストＤＢ２０、関係を満たす構文構造を関係リストＤＢ２１に記憶させる。
【００５０】
次に、制御部２は、コードエンティティ、データエンティティ、関係のリストを入力して、ソフトウェアモデルを構築する（ステップ３）。制御部２が構築したソフトウェアモデルの一例を図１１に示す。制御部２は、構築したソフトウェアモデルをソフトウェアモデルＤＢ２２に記憶させる。さらに、制御部２は、ソフトウェアモデルをソフトウェアモデルＤＢ２２から入力して、影響波及モデルを構築する（ステップＳ４）。制御部２が構築した影響波及モデルの一例を図１３に示す。制御部２は、構築した影響波及モデルを影響波及モデルＤＢ２３に記憶させる。
【００５１】
次に、制御部２は、ＡＰＩリストと、サンプルソフトウェアで発生した障害のリスト（障害履歴）とを入力して、波及行列を構築する（ステップＳ５）。構築した波及行列の一例を、図１７に示す。制御部２は、構築した波及行列を波及行列ＤＢ２４に記憶させる。
次に、制御部２は、、波及行列とソフトウェアの障害履歴を入力し、ＡＰＩ危険度を計算する（ステップＳ６）。制御部２は、計算したＡＰＩ危険度をＡＰＩ危険度ＤＢ１８に記憶させる。
【００５２】
このように本実施例は、データの依存関係や、ソースコードの制御依存関係に基づくグラフ構造（ソフトウェアモデル）を構築して、ＡＰＩの使用によって、ソフトウェアにおいて過去に発生した障害の発生箇所が受ける影響の度合いを求めている。そして、この影響の度合いに基づいてＡＰＩの使用が障害発生の遠因となった確率を推定している。従って、初期段階で取り除けるような表層的な問題点ではなく、ソフトウェアの構造的な障害の発生箇所を予測することが可能となる。
【実施例２】
【００５３】
上述した実施例1では、最尤推定法を用いて、影響波及モデルからＡＰＩの危険度を求めた。本実施例では、別の方法を用いてＡＰＩの危険度を求める方法を示す。なお、実施例１と多くの処理が同一であるので、その同一の箇所の説明は省略する。
【００５４】
本実施例は上述した実施例１とＡＰＩ危険度計算部１４における処理が異なる。このため、ＡＰＩ危険度計算部１４の処理について詳細に説明する。本実施例では、ＡＰＩ危険度計算部１４は、障害の起こり易さの度合いＡｉを次式（５）に従って求める。
【００５５】
【数５】
2010257091.tif 000007
【００５６】
上述した実施例１では、Ｅｉｊは、ＡＰＩｉからエンティティＸｊへの波及係数であるが、これをエンティティＸｊからＡＰＩｉへの影響波及の度合いの代用として用いる。すなわち、本実施例では、ＡＰＩの使用によって障害発生箇所が受ける影響度合いを、障害発生箇所がＡＰＩに及ぼす影響度合いとして使用し、ソフトウェアで過去に発生したすべての障害の発生箇所の影響度合いを加算してソフトウェアが使用するＡＰＩの危険度を算出している。
【００５７】
図１７に示す波及行列と、図１６に示すソフトウェア障害履歴の例から、｛Ａ１，Ａ２｝を計算すると、Ａ１＝０．７７５、Ａ２＝０．５００となる。ＡＰＩ危険度計算部１４は、このようにして得られた｛Ａ１，Ａ２，・・・，ＡＮ｝をＡＰＩの危険度として出力する。ＡＰＩの危険度の出力形式は、図１９に示す実施例１と同一である。
【００５８】
なお、ＡＰＩ危険度の値は相対値として意味があるが、絶対値としての意味は定義されない。すなわち、Ａ１とＡ２を比べてＡ１の方が大きい場合はＡ１の方が危険であるが、Ａ１の値が０．３だからといって、障害発生率やその期待値が常に０．３というわけではない。本実施理においては、上述した実施例１と同様の効果を得ることができると共に、ＡＰＩ危険度の算出が容易になるという効果を有している。
【実施例３】
【００５９】
上述した実施例１、実施例２では、ＡＰＩの危険度を求めて出力する方式について述べた。本実施例では、出力したＡＰＩの危険度を実際のソフトウェア開発プロジェクトに適用する方法について述べる。
本実施例の運用形態は、図２１に示すように準備段階と運用段階の二つに分かれる。準備段階では、サンプルソフトウェアとその障害履歴を入力として、各ＡＰＩの危険度を求め、データベースに蓄えておく。実施例１、実施例２でその具体的な内容について説明した。
運用段階では、準備段階で参照したサンプルソフトウェアとは異なる、別のソフトウェアを開発する開発プロジェクトが対象となる。ソフトウェア開発プロジェクトの中では、ソフトウェア全体はいくらかの部分に分けられ、作業もそれに応じて細かい作業に分割される。分割された作業をここではタスクと呼ぶ。タスクに必要な作業量はそれぞれのタスクで変化し、当初の見積もった作業量と一致することは少ない。タスクの難易度が高ければ想定以上の工数を必要とし、タスクの潜在リスクが高ければ、トラブルによる工程遅延が発生する。そこで、最終的にタスクに必要な作業量を正しく見積もる技術、またはできるだけ高い精度で見積もる技術が必要となる。本実施例はＡＰＩ危険度を用いて作業工数を見積もる。
【００６０】
本実施例の構成を図２２に示す。本実施例は、図２２に示すようにリスクポイント算出部２５と、見積もり補正部２６とをさらに備えている。リスクポイント算出部２５は、ＡＰＩ危険度ＤＢ１８からＡＰＩの危険度を取得して、ソフトウェア全体又はタスクにおけるリスクポイントを算出する。見積もり補正部２６は、リスクポイント算出部２５によって算出されたリスクポイントに基づいて作業工数の見積もりを補正する。
【００６１】
あるタスクＴｉにおいて、使用するＡＰＩが決まる段階に設計が進んだ時にリスクポイント算出部２５は、ＡＰＩ危険度によりリスクポイントを算出する。使用されるＡＰＩの集合を{ＡＰＩ１,ＡＰＩ２,・・・，ＡＰＩＭ}とする。ＡＰＩ危険度ＤＢ１８を参照すれば、各ＡＰＩのＡＰＩ危険度が判る。ＡＰＩｊのＡＰＩ危険度をＡｊとする。リスクポイントＲｉは、以下に示す式（６）で求められる。
【００６２】
【数６】
2010257091.tif 000008
【００６３】
式（６）中の関数ｆと関数ｇは開発プロセスに応じて設定される。特別な意図の無い標準的な場合には以下に示す式（７）（つまり恒等変換）とする。他の有力な代替候補は以下に示す式（８）である。
【００６４】
【数７】
2010257091.tif 000009
【００６５】
【数８】
2010257091.tif 000010
【００６６】
見積もり補正部２６は、得られたリスクポイントを元に、当初の見積もりを補正する。これにより工数見積もりやリスク判定の精度の向上が実現される。図２３には、リスクポイントから工数見積もりの補正値を得る表の一例を示す。この表はプロジェクトに事前に与えられ、例えば、記憶装置６に記憶しておくとよい。
【００６７】
ソフトウェアにはウェブアプリケーションや機器制御用組み込みアプリケーションなどのように、さまざまなタイプがあり、ソフトウェアの性質もタイプによって変化しうる。そこで、開発するソフトウェアのタイプごとに、「ＡＰＩの危険度」のデータベースを事前に別々に用意しておけば、プロジェクトの開始時に開発対象となるソフトウェアのタイプに応じて最適なデータベースを選択することができ、より精度の向上が見込める。開発するソフトウェアのタイプとして、例えば、ウェブアプリケーションや機器制御用の組み込みアプリケーションなどが挙げられる。
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【００６８】
上述した実施例は、本発明の好適な実施例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施が可能である。
【符号の説明】
【００６９】
１  危険度判定装置
２  制御部
１１  ソースコード
１２  ソフトウェアモデル構築部
１３  波及行列計算部
１４  ＡＰＩ危険度計算部
１５  ソースコードＤＢ
１６  ＡＰＩリストＤＢ
１７  サンプルソフトウェアの障害履歴ＤＢ
１８  ＡＰＩ危険度ＤＢ
１９  データエンティティリストＤＢ
２０  コードエンティティリストＤＢ
２１  関係リストＤＢ
２２  ソフトウェアモデルＤＢ
２３  影響波及モデルＤＢ
２４  波及行列ＤＢ
１１１  構文解析部
１１２  モデル要素抽出部
１３１  影響波及モデル構築部
１３２  波及行列構築部
【図１】
2010257091.tif 000011
【図２】
2010257091.tif 000012
【図３】
2010257091.tif 000013
【図４】
2010257091.tif 000014
【図５】
2010257091.tif 000015
【図６】
2010257091.tif 000016
【図７】
2010257091.tif 000017
【図８】
2010257091.tif 000018
【図９】
2010257091.tif 000019
【図１０】
2010257091.tif 000020
【図１１】
2010257091.tif 000021
【図１２】
2010257091.tif 000022
【図１３】
2010257091.tif 000023
【図１４】
2010257091.tif 000024
【図１５】
2010257091.tif 000025
【図１６】
2010257091.tif 000026
【図１７】
2010257091.tif 000027
【図１８】
2010257091.tif 000028
【図１９】
2010257091.tif 000029
【図２０】
2010257091.tif 000030
【図２１】
2010257091.tif 000031
【図２２】
2010257091.tif 000032
【図２３】
2010257091.tif 000033