(57)【要約】【課題】  リリース後のソフトウェアによる障害件数を予測することを可能とし、また、残存バグの進捗状況を知ることを可能にする。【解決手段】  本発明は、バグ毎のバグ検出時間、バグ発見件数を取得し、最も適合度の高い信頼度成長モデルの平均値関数を用いて該バグ発見件数の累積件数から残存バグを推定し、前記平均値関数を１回微分することにより求められたバグ生起確率関数を用いてバグ生起確率を求め、該バグ生起確率を用いてバグ生起確率曲線を描画し、バグ生起確率曲線から残存バグの収束状況を分類し、品質達成状況として出力し、収束状況判定手段による残存バグの収束状況から品質達成状況を評価し、残存バグの件数、残存バグの収束率及び残存バグの収束状況から総合評価を行う。【選択図】  図１
2014203330.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアの試験工程で検出されるバグの発生事象の動的挙動を確率モデルにより表現した信頼度成長モデルを用いてプロダクトの品質を評価するプロダクト品質評価装置であって、
バグ毎のバグ検出時間、バグ発見件数を取得し、最も適合度の高い信頼度成長モデルの平均値関数を用いて該バグ発見件数の累積件数から残存バグ件数を推定するバグ数推定手段と、
前記平均値関数を１回微分することにより求められたバグ生起確率関数を用いてバグ生起確率を求め、該バグ生起確率を用いてバグ生起確率曲線を描画するバグ生起確率曲線出力手段と、
前記バグ生起確率曲線から残存バグの収束状況を分類し、品質達成状況として出力する収束状況判定手段と、
前記収束状況判定手段による前記残存バグの収束状況から品質達成状況を評価する品質状況評価手段と、
前記残存バグの件数、残存バグの収束率及び前記残存バグの収束状況から総合評価を行う品質総合判定手段と、
を有することを特徴とするプロダクト品質評価装置。
【請求項２】
前記収束状況判定手段は、
前記バグ生起確率曲線から、
前記バグ生起確率曲線が残存バグ０件に収束しない；
試験が進行しているにも関わらず、前記バグ生起確率曲線値が増加、または、低下しない；
前記バグ生起確率曲線が残存バグ０件に収束；
のいずれかに分類し、品質達成状況として出力する手段を含む
請求項１記載のプロダクト品質評価装置。
【請求項３】
前記品質状況評価手段は、
前記残存バグの収束状況に基づいて、
試験が足りないため、追加試験または強化試験が必要；
試験観点、試験実施方法に不備があるため、試験計画を見直す必要がある；
試験完了；
のいずれであるかを判定し、判定結果を前記品質達成状況として出力する手段を含む
請求項１記載のプロダクト品質評価装置。
【請求項４】
前記品質総合判定手段は、
前記残存バグの件数、残存バグの収束率、前記残存バグの収束状況と、それぞれの閾値とを比較して、
試験が足りないため、追加試験または、強化試験が必要であるため、品質達成度は不十分；
試験観点、試験実施方法に不備があるため、試験計画を見直す必要があるため、品質達成度は不十分；
品質状況は良好なため、試験を終了；
のいずれであるかを判定する手段を含む
請求項１記載のプロダクト品質評価装置。
【請求項５】
ソフトウェアの試験工程で検出されるバグの発生事象の動的挙動を確率モデルにより表現した信頼度成長モデルを用いてプロダクトの品質を評価するプロダクト品質評価方法あって、
バグ数推定手段、バグ生起確率曲線出力手段、収束状況判定手段、品質状況評価手段、品質総合判定手段を有する装置において、
前記バグ数推定手段が、バグ毎のバグ検出時間、バグ発見件数を取得し、最も適合度の高い信頼度成長モデルの平均値関数を用いて該バグ発見件数の累積件数から残存バグ件数を推定するバグ数推定ステップと、
前記バグ生起確率曲線出力手段が、前記平均値関数を１回微分することにより求められたバグ生起確率関数を用いてバグ生起確率を求め、該バグ生起確率を用いてバグ生起確率曲線を描画するバグ生起確率曲線出力ステップと、
前記収束状況判定手段が、前記バグ生起確率曲線から残存バグの収束状況を分類し、品質達成状況として出力する収束状況判定ステップと、
前記品質状況評価手段が、前記収束状況判定手段による前記残存バグの収束状況から品質達成状況を評価する品質状況評価ステップと、
前記品質総合判定手段が、前記残存バグの件数、残存バグの収束率及び前記残存バグの収束状況から総合評価を行う品質総合判定ステップと、
を行うことを特徴とするプロダクト品質評価方法。
【請求項６】
前記収束状況判定ステップにおいて、
前記バグ生起確率曲線から、
前記バグ生起確率曲線が残存バグ０件に収束しない；
試験が進行しているにも関わらず、前記バグ生起確率曲線値が増加、または、低下しない；
前記バグ生起確率曲線が残存バグ０件に収束；
のいずれかに分類し、品質達成状況として出力する
請求項５記載のプロダクト品質評価方法。
【請求項７】
前記品質状況評価ステップにおいて、
前記残存バグの収束状況に基づいて、
試験が足りないため、追加試験または強化試験が必要；
試験観点、試験実施方法に不備があるため、試験計画を見直す必要がある；
試験完了；
のいずれであるかを判定し、判定結果を前記品質達成状況として出力する
請求項５記載のプロダクト品質評価方法。
【請求項８】
前記品質総合判定ステップにおいて、
前記残存バグの件数、残存バグの収束率、前記残存バグの収束状況と、それぞれの閾値とを比較して、
試験が足りないため、追加試験または、強化試験が必要であるため、品質達成度は不十分；
試験観点、試験実施方法に不備があるため、試験計画を見直す必要があるため、品質達成度は不十分；
品質状況は良好なため、試験を終了；
のいずれであるかを判定する
請求項５記載のプロダクト品質評価方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロダクト品質評価装置及び方法に係り、特に、ソフトウェア開発過程の試験工程以降における品質情報から残存バグ件数を予測するためのプロダクト品質評価装置及び方法に関する。
【背景技術】
【０００２】
情報システムが経済・社会の様々な分野で必要不可欠なものとなっている現在、信頼性の高いソフトウェア開発に対する要求が高まっている。信頼性の高いソフトウェアを開発するためには、ソフトウェア品質を定量的に評価し、残存バグ件数を高い精度で予測することが、当該ソフトウェアを用いたサービスの開始の判断を適切に実施するためにも不可欠である。
【０００３】
残存バグ件数を推定する方法として広く利用されているのは、試験工程で検出されるバグの累積値の傾向から残存バグ件数を推定するソフトウェア信頼度成長モデル（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 (2nd 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）毎に閾値を設定しておき、残存バグ収束状況情報の各項目の値と閾値を比較して以下の３つのパターンのいずれであるかを判定する。
【００５３】
パターンａ：試験が足りないため、追加試験または強化試験が必要。
【００５４】
パターンｂ：試験観点、試験実施方法に不備があるため、試験計画を見直す必要がある。
【００５５】
パターンｃ：試験完了
上記のいずれかのパターンを品質達成状況として出力する。
【００５６】
次に、上記のステップ１４０の処理について説明する。
【００５７】
図８は、本発明の一実施の形態におけるステップ１４０の詳細処理のフローチャートである。
【００５８】
ステップ１４２）  品質総合判定部１３０は、ステップ１００で得られた残存バグ予測値、ステップ１２０で得られた残存バグ収束状況、ステップ１３０で得られた品質達成状況の各情報に基づいて、品質状況を判定する。
【００５９】
具体的には、残存バグ収束率、残存バグ件数、残存バグ収束状況から、以下の３つのパターンに対して品質を判定する。
【００６０】
パターンａ）試験が足りないため、追加試験または強化試験が必要であり、品質達成度は不十分。
【００６１】
パターンｂ）試験観点、試験実施方法に不備があるため、試験計画を見直す必要があるため、品質達成度は不十分。
【００６２】
パターンｃ）品質状況は良好なため、試験を終了。
【００６３】
上記のパターンａ，ｂ，ｃのいずれかを品質判定結果として出力する。例えば、図９の例では、評価結果として、プロジェクト毎に、残存バグ予測値、予測値の信頼度、品質状況パターン、総合品質評価等の項目からなるレコードを出力する。
【００６４】
上記の図１に示すプロダクト品質評価装置の各構成要素の動作をプログラムとして構築し、プロダクト品質評価装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【００６５】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００６６】
１  ユーザ端末
１０  信頼度成長モデルバグ数推定部
２０  バグ生起確率関数算出部
１００  プロダクト品質評価装置
１１０  ソフトウェア信頼度成長モデル計算部
１２０  収束状況判定部
１３０  品質総合判定部
１４０  メモリ
【図１】
2014203330.tif 000003
【図２】
2014203330.tif 000004
【図３】
2014203330.tif 000005
【図４】
2014203330.tif 000006
【図５】
2014203330.tif 000007
【図６】
2014203330.tif 000008
【図７】
2014203330.tif 000009
【図８】
2014203330.tif 000010
【図９】
2014203330.tif 000011