(57)【要約】      （修正有）【課題】ソフトウェアに不具合が組み込まれたバージョンに関する情報を正確、かつ、効率的に特定する。【解決手段】ソフトウェア評価システムは、作成中のソフトウェアを、適宜バージョン情報を付加して管理し、また、各バージョンのソフトウェアの評価実施状況と評価結果とを関連づけて評価履歴情報として記憶する。未評価のバージョンのソフトウェアを評価して不具合が発生したとき、過去の評価履歴情報を用いて、その不具合が組み込まれたバージョン情報を特定する。【選択図】図３
2019114043.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアを評価するソフトウェア評価システムであって、
前記ソフトウェアのバージョンを識別するバージョン識別情報と、該識別情報によって識別される前記ソフトウェアのソースコードの情報とを関連付けて記憶したバージョン情報を管理するバージョン管理手段と、
前記ソフトウェアの評価を行うべき項目としての試験項目と該試験項目についての結果の判断基準を含む評価リストに関する評価を実行する評価実行手段と、
前記評価の結果を判断する結果判断手段と、
前記ソフトウェアのバージョン識別情報を指定して、該識別情報に対応するソフトウェアの評価を前記評価実行手段に指示するとともに、前記結果判断手段から該評価の結果を取得し、前記ソフトウェアのバージョン識別情報と、前記評価の実施状況及び結果を含む評価状況情報とを関連付けて記憶する評価履歴情報から、前記ソフトウェアの不具合が発生したバージョンの候補となる不具合発生バージョン候補を抽出し、該不具合発生バージョン候補から、前記ソフトウェアの不具合が発生したバージョンを特定する不具合バージョン探索手段と、
を備えることを特徴とするソフトウェア評価システム。
【請求項２】
前記不具合バージョン探索手段は、前記ソフトウェアの評価において不具合があると判断された場合に、該ソフトウェアに該不具合が発生したバージョンを特定することを特徴とする請求項１に記載のソフトウェア評価システム。
【請求項３】
前記評価状況情報は、前記評価をいまだ実行していない状況であることを示す未評価情報と、前記評価の結果として、不具合があることを示す不具合情報及び不具合がないことを示す合格情報とを含み、
前記不具合バージョン探索手段は、前記ソフトウェアについて、前記評価履歴情報に、前記合格情報が記憶されていない場合には、前記バージョン管理手段によって管理されているバージョンのうちの全てのバージョンを、前記不具合が発生したバージョンの候補として抽出し、前記評価履歴情報に、前記合格情報が記憶されている場合には、該合格情報に関連付けられたバージョンのうち最新のバージョンより後のバージョンを、前記不具合が発生したバージョンの候補として抽出することを特徴とする請求項１又は２に記載のソフトウェア評価システム。
【請求項４】
１以上の前記評価リストを有し、
前記評価状況情報は、前記評価リストごとの、前記未評価情報、前記不具合情報及び前記合格情報を含み、
いずれの評価リストについて前記評価を実行するかを決定する決定手段を有し、
前記不具合バージョン探索手段は、前記評価実行手段が、前記決定手段によって決定された前記評価リストについて評価を実施し、かつ、前記結果判断手段が判断した該評価の結果を取得し、前記ソフトウェアについて、前記評価履歴情報に、前記評価リストについての、前記合格情報が記憶されていない場合には、前記バージョン管理手段によって管理されているバージョンのうちの全てのバージョンを、前記不具合が発生したバージョンの候補として抽出し、前記評価履歴情報に、前記評価リストについての、前記合格情報が記憶されている場合には、該合格情報に関連付けられたバージョンのうち最新のバージョンより後のバージョンを、前記不具合が発生したバージョンの候補として抽出することを特徴とする請求項３に記載のソフトウェア評価システム。
【請求項５】
いずれの評価リストを優先して前記評価を実行すべきかについての優先度情報を有し、
前記決定手段は、前記優先度情報に基づいて、前記評価を実行すべき評価リストを決定することを特徴とする請求項４に記載のソフトウェア評価システム。
【請求項６】
前記優先度情報に、所定のバージョン更新回数の範囲内で評価が実施されていない前記評価リストを、評価を実施する評価リストとして決定することが含まれており、
前記決定手段は、
前記評価履歴情報を参照し、前記所定のバージョン更新回数の範囲内で評価が実施されている前記評価リストの有無を調査し、該所定のバージョン更新回数の範囲内で評価が実施されていない評価リストを、評価を実施する評価リストとして決定することを特徴とする請求項５に記載のソフトウェア評価システム。
【請求項７】
前記優先度情報に、前記ソフトウェアのソースコードのファイル情報と、前記評価リストを関連付けて、実施すべき評価リストの優先度を決定するための情報が含まれており、
前記決定手段は、
前記バージョン管理手段から、 前記ソフトウェアの評価対象バージョンのソースコー
ドと、該評価対象バージョンの直前のバージョンのソースコードとの差分情報を取得し、該差分情報において差分を有するファイルについて、前記優先度情報を参照して、実施する評価リストを決定することを特徴とする請求項５又は６に記載のソフトウェア評価システム。
【請求項８】
前記評価リストの評価を実行する環境に関する情報である評価環境情報を、該評価環境情報のバージョンを識別する環境識別情報と関連付けて有し、
前記評価履歴情報は、前記ソフトウェアのバージョン識別情報と、前記評価状況情報と、該評価を実施したときの前記評価環境情報を識別する前記環境識別情報とを関連付けて記憶しており、
前記不具合バージョン探索手段は、
前記ソフトウェアのバージョン識別情報とともに前記環境識別情報を特定して、前記評価実行手段に前記評価を実行させ、
前記ソフトウェアの不具合が発生したバージョンに対する前記評価に関する前記評価環境情報と、前記評価履歴情報とを比較して、前記環境に基づく不具合を排除して、前記不具合が発生したバージョンを特定することを特徴とする請求項１乃至７のいずれか１項に記載のソフトウェア評価システム。
【請求項９】
前記評価状況情報は、前記評価を実施した者が当該システムか否かを示す評価者情報を含み、
前記不具合バージョン探索手段は、前記不具合発生バージョンの候補のすべてについて評価結果において不具合があり、かつ、前記合格情報に関連付けられたバージョンのうち最新のバージョンについての前記評価を実施した者がシステムでない場合には、前記合格情報に関連付けられたバージョンについての評価を指示することを特徴とする請求項１乃至８のいずれか１項に記載のソフトウェア評価システム。
【請求項１０】
請求項１乃至９のいずれか１項に記載のソフトウェア評価システムとして、コンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア評価システムに関し、特に、ソフトウェアの不具合が発生した際に不具合が組み込まれたバージョンを自動で探索、抽出するシステムに関するものである。
【背景技術】
【０００２】
ソフトウェアの不具合が発生した場合に、変更ファイルを探索、抽出する技術としては、特許文献１に記載されたものがある。特許文献１記載技術は、「テストを実施した際に処理が通過する経路」を記憶するテスト項目実行部と、評価対象ソフトウェアのリビジョン管理機能、ソフトウェアの差分を抽出する機能を持つシステムである。このシステムは、テストにより不具合を検出すると、不具合発生時の処理の経路に着目し、前記リビジョン管理機能及びソフトウェアの差分を抽出する機能から、不具合発生時の経路に関する修正を行ったリビジョン情報を算出するものである。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−１１３７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１記載の技術は、モジュールに対する静的解析による評価といった、評価対象ソフトウェアの規模が小さい場合に有効である。
ところが、評価対象ソフトウェアの規模が大きい場合には、不具合が発生するまでに様々な経路をたどる。たどった経路が長ければ長いほど、たどった経路上に前回以前のリビジョンのソフトウェアとの差分が存在する可能性が高くなる。差分の中には不具合と関係のない差分も存在する。評価対象ソフトウェアの規模が大きく、かつ毎リビジョンでテストを行っていないとすると、経路上の不具合と関係のない差分を捉えて誤報知する可能性がある。
【０００５】
本発明は、上記課題を鑑みたものであって、不具合が組み込まれたバージョン情報を正確かつ効率的に特定することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、本発明は、
ソフトウェアを評価するソフトウェア評価システムであって、
前記ソフトウェアのバージョンを識別するバージョン識別情報と、該識別情報によって識別される前記ソフトウェアのソースコードの情報とを関連付けて記憶したバージョン情報を管理するバージョン管理手段と、
前記ソフトウェアの評価を行うべき項目としての試験項目と該試験項目についての結果の判断基準を含む評価リストに関する評価を実行する評価実行手段と、
前記評価の結果を判断する結果判断手段と、
前記ソフトウェアのバージョン識別情報を指定して、該識別情報に対応するソフトウェアの評価を前記評価実行手段に指示するとともに、前記結果判断手段から該評価の結果を取得し、前記ソフトウェアのバージョン識別情報と、前記評価の実施状況及び結果を含む評価状況情報とを関連付けて記憶する評価履歴情報から、前記ソフトウェアの不具合が発生したバージョンの候補となる不具合発生バージョン候補を抽出し、該不具合発生バージョン候補から、前記ソフトウェアの不具合が発生したバージョンを特定する不具合バージ
ョン探索手段と、
を備えることを特徴とする。
【０００７】
本発明は、上記ソフトウェア評価システムとして、コンピュータを機能させることを特徴とするプログラムである。
【発明の効果】
【０００８】
以上説明したように、本発明によれば、評価対象ソフトウェアの不具合が組み込まれたバージョン情報を正確かつ効率的に特定することができる。
【図面の簡単な説明】
【０００９】
【図１】実施例１におけるソフトウェア評価システムの機能ブロック図
【図２】実施例１におけるソフトウェア評価システムのハードウェア構成
【図３】実施例１におけるソフトウェア評価処理のフローチャート
【図４】実施例１におけるソフトウェア評価システムの評価履歴情報の推移を示す図
【図５】実施例２におけるソフトウェア評価システムの機能ブロック図
【図６（Ａ）】実施例２の評価項目の選択の優先順位を決めるための情報を示す図
【図６（Ｂ）】実施例２の評価項目の選択の優先順位を決めるための情報を示す図
【図６（Ｃ）】実施例２の評価項目の選択の優先順位を決めるための情報を示す図
【図６（Ｄ）】実施例２の評価項目の選択の優先順位を決めるための情報を示す図
【図６（Ｅ）】実施例２の評価項目の選択の優先順位を決めるための情報を示す図
【図７】実施例２におけるソフトウェア評価処理のフローチャート
【図８】実施例２におけるソフトウェア評価システムの評価履歴情報を示す図
【図９】実施例３におけるソフトウェア評価システムの機能ブロック図
【図１０】実施例３におけるソフトウェア評価処理のフローチャート
【図１１】実施例４におけるソフトウェア評価処理のフローチャート
【図１２（Ａ）】実施例２におけるソフトウェア評価処理の評価項目を示す表
【図１２（Ｂ）】実施例２におけるソフトウェア評価処理の評価項目を示す表
【図１２（Ｃ）】実施例２におけるソフトウェア評価処理の評価項目を示す表
【図１２（Ｄ）】実施例２におけるソフトウェア評価処理の評価項目を示す表
【図１３】実施例３におけるソフトウェア評価処理の評価履歴情報を示す図
【発明を実施するための形態】
【００１０】
以下に図面を参照して、この発明を実施するための形態を、実施例に基づいて例示的に詳しく説明する。本発明の趣旨を逸脱しない範囲内で実施例の構成を適宜変形したり変更したりすることにより得られる構成も本発明に含まれる。以下の複数の実施例の構成を適宜組み合わせて得られる構成も、本発明に含まれる。また、各実施例における機能および処理はそれぞれ単一のコンピュータ装置で実現してもよいし、必要に応じた複数のコンピュータ装置による分散処理によって実現するようにしてもよい。複数のコンピュータ装置で構成される場合は、互いに通信可能なようにＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＬＡＮ）などで接続されている。あるいは、機能および処理の一部をクラウドコンピューティングによって実現してもよい。
【実施例１】
【００１１】
本実施例においてソフトウェア評価システムは、コンピュータシステム２０１上でプログラムを実行することで実現でき、そのハードウェア構成を図２に示す。図２の本体部２０２のハードディスク２０８には、ソフトウェア評価システムの各機能を実現するためのプログラムが格納される。中央処理装置（ＣＰＵ）２０６は、プログラム及び各種データを主記憶装置２０７にロードして実行することで、コンピュータシステム２０１はソフトウェア評価システムとして動作する。なお、表示装置２０３は、本体部２０２からの指示
により画面表示を行う。また、キーボード２０４は、このコンピュータシステム２０１にユーザの指示や文字情報を入力するためのものである。さらに、マウス２０５は、表示装置２０３上の任意の位置を指定することによりその位置に表示されていたアイコン等に応じた指示を入力するためのものである。
【００１２】
図１は本実施例によるソフトウェア評価システム１００の機能ブロック図である。
ソフトウェア評価システム１００は、バージョン管理手段１０１、評価内容決定部１１１、評価実施部１２１を持つ。また、バージョン情報１０２と評価情報１３１を持つ。
前記バージョン管理手段１０１は、バージョン情報１０２へのアクセス手段を持つ。バージョン情報１０２には、少なくとも、ソフトウェアのバージョン番号とソースコード情報とが紐付けられて格納される。前記ソースコード情報は、バージョン毎にバージョン情報１０２へ格納される。バージョン毎にソースコードを全て格納してもよいし、バージョン間の差分情報のみを格納してもよい。その他に、バージョン更新時の日時情報や、更新者情報などを付随させて格納してもよい。ここで、ソフトウェアのバージョン番号がバージョン識別情報に対応する。
バージョン管理手段１０１は、図示しないソフトウェアの更新指示を受けると、バージョン情報１０２へ前述した格納情報を格納する。このとき、バージョン管理手段１０１は、ソフトウェアの更新指示ごとに前記ソフトウェアのバージョン番号を更新するものでもよいし、ユーザからバージョン更新指示を受けたときだけバージョン番号を更新するものでもよい。後者の場合は、同一のバージョン番号に対して、ソフトウェア更新指示が複数回なされることがあるが、内部的な更新管理情報を持ち、更新指示ごとのソースコード情報を格納しても良い。
また、バージョン管理手段１０１は、外部からの指示に従い、バージョン情報１０２内の情報を外部へ伝達する手段を持つ。具体的には、最新のバージョン番号を通知する機能と、指示されたバージョン番号に対応するソースコード情報を外部へ渡す手段を持つ。
このとき、バージョン情報１０２にソフトウェアの差分情報のみが格納されているとしても、差分情報のみを渡すのではなく、ソフトウェア全体の情報に整形して渡す。また、差分情報のみを渡すか、ソフトウェア全体の情報として渡すかをユーザが任意に選択できるようにしても良い。
【００１３】
評価情報１３１は、評価履歴情報１３２、評価設定情報１３３、評価リスト情報１３４から成る。
評価設定情報１３３には、評価手段に応じた設定情報が格納される。後述の評価実行手段１２３が複数の評価手段を持つ場合には、評価手段に応じた設定情報が格納される。
つまり、シミュレータを用いての評価であれば、評価対象ソフトウェアを動作させる仮想環境についての設定情報が格納される。評価対象ソフトウェアが、機器組込系のソフトウェアならば、制御対象の機器の振る舞いを模擬するような設定情報が格納される。前記評価手段が静的解析である場合には、評価対象ソフトウェアにもし解析対象から除外したい定義情報があれば、設定情報として除外対象定義情報が格納される。
尚、本実施例では評価設定情報１３３を評価情報１３１に含めたが、バージョン情報１０２へ含めて、評価設定情報１３３と、評価対象ソフトウェアとを関連づけて管理してもよい。
理由は、評価設定情報１３３は評価対象ソフトウェアと密接な関係を持つことと、評価対象ソフトウェアの更新に伴い、評価設定情報１３３も更新を要することがあるためである。
評価リスト情報１３４には、評価対象ソフトウェアを評価するための試験項目、及び試験の成否の判断基準情報が関連付けられて格納される。評価実行手段１２３が複数の評価手段を持つ場合には、評価手段に応じた試験項目が格納される。
評価履歴情報１３２には、ソフトウェア評価システム１００が行った評価の履歴情報が格納される。評価履歴情報１３２には、評価を終えた評価対象ソフトウェアのバージョン
番号と、後述の結果判断手段１２４の判断結果、すなわち評価の成否が関連づけられて格納される。評価履歴情報は、評価をいまだ実行していない状況という実施状況に関する情報である未評価情報と、評価結果として、不具合がある（「ＮＧ」である）ことを示す不具合情報と、不具合がない（「ＯＫ」である）ことを示す合格情報を含む評価状況情報を含む。
また、評価履歴情報１３２にはソフトウェア評価システム１００が行った評価の履歴情報が格納されるものとしているが、ソフトウェア評価システム１００に、ユーザが評価履歴情報１３２を更新する手段を持たせても良い。その場合は、評価履歴情報１３２に、評価実施部１２１の実施結果情報と、「ユーザによる評価ＯＫ」という情報が格納される。
【００１４】
評価内容決定部１１１は、ソフトウェア評価システム１００が、評価実施部１２１で実施する評価内容を決定するもので、具体的には、ソフトウェアバージョン番号を決定する機関である。また、評価を開始するトリガ情報を受け取り、評価開始判断を行う。
評価指示受信手段１１４は評価内容決定部１１１の一機能であり、指示を受けると評価の開始可否を判断して、可能であれば評価実施部１２１に、対象のソフトウェアバージョン番号情報を渡す。評価指示受信手段１１４の指示の受け口は、不図示のユーザからの指示、または、および、バージョン管理手段１０１によるソフトウェアの更新通知である。ただし、評価指示受信手段１１４がユーザからの指示またはバージョン管理手段１０１からのソフトウェア更新通知受信時に、ソフトウェアのバージョン番号情報を得られない場合がある。この場合には、評価対象バージョン番号を、バージョン管理手段１０１に格納される最新バージョン番号とする。このため、評価指示受信手段１１４は、バージョン管理手段１０１へ最新のバージョン番号情報を問い合わせ、返送情報を評価実施部１２１へ渡す。
不具合バージョン探索手段１１３は、不具合が見つかったソフトウェアに対して、どのバージョンのソフトウェアで再評価を実施するかを決定する機関である。不具合バージョン探索手段１１３は、当該不具合が発生した、すなわち当該不具合が初めて組み込まれたバージョン番号を特定するまで動作する。
不具合バージョン探索手段１１３は、評価履歴情報１３２を参照し、前回不具合が見つからなかったバージョン番号情報を取得する。前回不具合が見つからなかったバージョン番号＋１から、今回不具合を見つけたバージョン番号−１までのいずれかのバージョン番号を不具合発生バージョン候補として選択する。いずれのバージョン番号を最優先とするかは、前回不具合が見つからなかったバージョン番号＋１から昇順としてもよいし、今回不具合を見つけたバージョン番号−１から降順としてよい。また、隣接する２つのバージョンについて、ソフトウェアの差分情報を取得し、最も変更量が多いバージョンを最優先としてもよい。
【００１５】
評価実施部１２１は、評価環境構築手段１２２と、評価実行手段１２３、結果判断手段１２４を持つ。評価内容決定部１１１からの指示をトリガに動作し、処理が終了すると、評価内容決定部１１１へ処理終了を通知する。
評価環境構築手段１２２は、評価を実行可能な環境を整える手段である。具体的には、評価内容決定部１１１から指示されたバージョン番号情報に従い、バージョン管理手段１０１から、指示されたバージョン番号の評価対象ソースコード情報を取得する。
また、評価環境構築手段１２２は、評価設定情報１３３から評価に必要な設定情報を取得し、評価リスト情報１３４を実行可能な環境を構築する。
例えば、評価リスト情報１３４の評価内容がシミュレータである場合には、評価環境構築手段１２２は、評価設定情報１３３から評価対象ソフトウェアを動作させる仮想環境についての設定情報を取得する。評価内容決定部１１１からの指示をうけたときに、評価リスト情報１３４に記載の全ての評価が行えるよう環境を整えてもいいし、後述の評価実行手段１２３が評価を終える毎に環境構築要否を判断して、環境を整えても良い。
評価実行手段１２３は評価リスト情報１３４記載の評価を実行する手段である。
具体的には、たとえばシミュレータを用いての評価であれば、仮想環境上で評価対象ソフトウェアを解釈・実行するＣＰＵシミュレータと、装置を模擬する装置シミュレータ、及び両者の連携処理を取り持つ連携システムを指す。前記連携システムが前記ＣＰＵシミュレータと装置シミュレータを連携駆動させ、その上で評価リスト情報１３４に記載の試験項目を実行させる。
静的解析であれば、静的解析手段へ、評価対象ソフトウェアへのパス情報や解析の除外対象定義情報、結果の出力定義等を送り、静的解析を行わせる。
結果判断手段１２４は、評価実行手段１２３の実行中、または実行終了後に動作する。結果判断手段１２４は、前記評価実行手段１２３による実行結果と、評価リスト情報１３４の成否の判断基準情報をもとに、成否を判断する。判断結果を評価履歴情報１３２に格納する。評価実施部１２１は、結果判断手段１２４実行時に、評価内容決定部１１１から渡された評価を全て終えたか否かを確認し、終えている場合には評価内容決定部１１１へ終了を通知する。
以上により、図１の本実施例によるソフトウェア評価システム１００の機能ブロック図についての説明を終える。
【００１６】
以下に本実施例の具体的な動作について、図３のフローチャートを用いて説明する。
図４は本実施例の評価履歴情報１３２の例である。
図４の（Ａ）は、いま、評価対象のソフトウェアについて、バージョン番号１．１及び１．４にて評価経験が有り、当時の評価結果は「ＯＫ」であったことを示している。
ソフトウェア評価システム１００は、評価指示受信手段１１４が不図示の外部モジュールからソフトウェア評価指示を受けると、評価実施部１２１へバージョン番号情報を渡す（Ｓ３０１）。評価実施部１２１は、評価環境構築手段１２２にて、仮想環境上にソフトウェアを評価可能な環境を構築する（Ｓ３０２）。まず、評価指示受信手段１１４から渡されたバージョン番号のソフトウェアを、バージョン管理手段１０１から取得する。次いで、評価情報１３１から、評価実行手段が使用するための評価設定情報１３３を取得する。
環境構築を終えると、評価を実行する（Ｓ３０３）。まず評価情報１３１から評価リスト情報１３４を取得し、評価環境構築手段１２２で構築した環境上で、前記評価リスト情報１３４の項目を順次実行する。
評価リストの実行中に、もし評価を続けられない重篤な不具合が発生した場合は、結果「ＮＧ」と判定し、評価を中断する。そうでなければ、実行状況と評価リスト情報１３４に格納される成否の判断基準情報とを照会し、結果の成否を判断する。判断を行うタイミングは、評価リストの実行中、または評価リストの項目を全て終了した段階いずれでもいい。
たとえば評価手段がシミュレーションの場合には、シミュレーション実行ログと、評価リスト情報１３４の成否の判断基準情報をもとに、成否を判断する。評価手段が静的解析の場合は、解析結果が評価リスト情報１３４に格納されている基準値を満たすか否かで成否を判定する。この、評価結果の判断方法については既知の技術であり、本発明の趣旨ではないため詳述を省略する。評価リスト内の項目の実行結果について、いずれかひとつでも「ＮＧ」の項目が有れば、評価結果を「ＮＧ」と判定する。
Ｓ３０３での評価を中断、または終了すると、評価対象バージョンのソフトウェアの成否が算出される。評価実施部１２１は、この成否情報と、ソフトウェアのバージョン番号情報とを関連づけて、評価履歴情報１３２へ格納すると共に、評価内容決定部１１１へ処理終了を通知する（Ｓ３０４）。ここで、評価履歴情報１３２に格納する成否情報について、評価「ＮＧ」という結果のみでもよいし、評価リスト内の、実際に不具合が発生した試験項目の識別情報と試験「ＮＧ」という結果とを関連づけて格納してもよい。本実施例では、前者の取り扱いとする。
【００１７】
評価内容決定部１１１は、評価結果の成否により振る舞いを変える。評価指示受信手段
１１４は、評価の結果が「ＯＫ」であれば（Ｓ３０５）、現在の状態が「不具合探索中」ではないため（Ｓ３０６）、評価終了と判断して処理を終了する。
評価の結果が「ＮＧ」であれば（Ｓ３０５）、不具合バージョン探索手段１１３に処理を渡す。ここでは、評価結果「ＯＫ」が合格情報、評価結果「ＮＧ」が不具合情報に対応する。
不具合バージョン探索手段１１３は、評価履歴情報１３２から、最後に評価「ＯＫ」であったバージョン番号情報を取得する。図４（Ａ）のとおり、最後に評価「ＯＫ」であったバージョン番号はバージョン１．４であったとする。たとえば、現在評価を行って、結果「ＮＧ」であったバージョン番号がバージョン１．８だったとすると、評価履歴情報１３２の格納情報は図４の（Ｂ）のとおりとなる。従って、不具合はバージョン１．５から１．８までの間に発生するようになったと予測できる（Ｓ３０７、Ｓ３０８）。不具合発生バージョンを突き止めるため、上記バージョン１．５から１．７についても評価を行う。まず手始めにどのバージョンの評価を行うかを決定する。ここで、次のバージョンの決定方法を、１．５から昇順としても、１．７から降順としても、バージョン間のソースコードの変更差分から算出しても良い。
たとえば、バージョン１．６を評価対象のバージョン番号として算出したとする。評価実施バージョン番号が決定したため、評価内容決定部１１１は、評価実施部１２１へ、再び評価指示を発布する（Ｓ３０９）。
評価実施部１２１は、再びＳ３０２からＳ３０４に示す方法で、バージョン番号１．６の評価を行い、結果を評価内容決定部１１１へ返す。評価内容決定部１１１は、結果を不具合バージョン探索手段１１３へ渡す。
たとえば、今度は評価結果「ＯＫ」だった場合に（Ｓ３０５）、不具合バージョン探索手段１１３は不具合探索中であるため（Ｓ３０６）、不具合発生バージョンを特定出来たか否かを判断する（Ｓ３０７）。
このとき、評価履歴情報１３２は図４（Ｃ）のようになり、最後に評価「ＯＫ」であったバージョン番号がバージョン１．６であったため不具合はバージョン１．７、または１．８のいずれかで発生するようになったと予測できる（Ｓ３０７、Ｓ３０８）。
不具合バージョン探索手段１１３は、バージョン１．８は評価済みのため、今度はバージョン１．７について、評価実施部１２１へ評価指示を出す（Ｓ３０９）。
評価実施部１２１は、再びＳ３０２からＳ３０４に示す方法で、バージョン番号１．７の評価を行い、結果を評価内容決定部１１１へ返す。評価内容決定部１１１は、結果を不具合バージョン探索手段１１３へ渡す。
いま、図４（Ｃ）において、バージョン１．７の評価を実施したため、結果の成否によらず、未探索バージョンがなくなる（Ｓ３０７）。バージョン１．７の評価結果が「ＮＧ」であれば、不具合発生バージョンを１．７とし、評価結果が「ＯＫ」であれば、不具合発生バージョンを１．８として、ユーザへ報知する（Ｓ３１０）。報知方法は、例として、ディスプレイに表示する、ログファイルへ残す、ユーザへメールするといった方法が挙げられる。
以上のようにして、不具合の発生したソフトウェアバージョン番号を特定することができる。
【００１８】
尚、本実施例ではソフトウェア評価システム１００の評価設定情報１３３を、変更されないものとして評価情報１３１に含めたが、随時変更される場合には、ソースコードと同様にバージョン情報１０２に含めても良い。
この場合には、バージョン管理手段１０１は、評価設定情報１３３のみの更新についてもバージョン番号を更新する。評価環境構築手段１２２は、評価設定情報１３３を、評価情報１３１からではなくバージョン情報１０２から、バージョン管理手段１０１を介して取得する。不具合発生時には既に述べた処理手順で不具合の発生境界を算出することができる。
また、本実施例では、評価履歴情報１３２に、「評価結果ＯＫ」の情報が格納されてい
るものとしたが、評価履歴情報１３２に、「評価結果ＯＫ」の情報が格納されていないケースも有り得る。たとえば、ソフトウェア評価システム１００の運用開始直後には、評価結果が存在しない。
図３のＳ３０８にて、評価内容決定部１１１は、評価実施部１２１から不具合発生情報を受けると、不具合バージョン探索手段１１３により次に実施する評価内容を決定する。
このとき、不具合バージョン探索手段１１３は、評価履歴情報１３２を参照し、実施した評価項目における、直近の評価「ＯＫ」の履歴を探す。
ここで、評価「ＯＫ」の履歴が一度も存在しないときには、バージョン情報１０２上の全てのバージョンを不具合発生バージョン候補として取り扱う。
上記の方法で、当該評価における評価「ＯＫ」の情報が評価履歴情報１３２に存在しない場合についても不具合を探索することができる。
【実施例２】
【００１９】
実施例１では、評価リスト情報１３４は単一であって、常に同じ試験項目を用いて評価対象ソフトウェアを評価する方法について述べた。
しかしながら、評価リスト情報１３４の項目量が多い場合に、評価対象ソフトウェアのバージョン更新期間内に、評価リスト情報１３４の全項目を終えられない場合がある。もしくは、ソフトウェアの更新内容によって、試験項目を変更したい場合が有る。
実施例２では、評価リスト情報１３４が１以上の評価リストを持つこととし、複数の評価リストを持てるようにする。平時は複数の評価リストから所望のリストを用いて自動的に評価を行い、不具合を発見した場合に、不具合の発生したソフトウェアバージョン番号を特定するシステム、及びその方法について述べる。
図５は本実施例におけるソフトウェア評価システム１００の機能ブロック図である。
ソフトウェア評価システム１００は、バージョン管理手段１０１及びバージョン情報１０２、評価内容決定部１１１、評価実施部１２１、評価情報１３１から構成される。
バージョン管理手段１０１及び、バージョン情報１０２は実施例１と同一であるため説明を省略する。
評価情報１３１は、評価履歴情報１３２、評価設定情報１３３、評価リスト情報１３４、評価優先度情報１３５から成る。
評価設定情報１３３は実施例１で述べたものと同一であるため説明を省略する。
【００２０】
次いで、評価リスト情報１３４を説明するが、説明に先立ち、評価対象ソフトウェアについて述べる。
本実施例では、ソフトウェア評価システム１００は、インクジェットプリンタ、レーザービームプリンタなどの画像形成装置に組み込まれるソフトウェアを評価するものとする。
従って、評価リスト情報１３４にも、画像形成装置に組み込まれるソフトウェア用の評価リストが格納される。
より詳細に評価リスト情報１３４を説明するため、まず画像形成装置の説明を行う。
画像形成装置は、いくつかの印刷設定を持ち、ユーザの要求に対して様々な印刷設定を組み合わせてプリントを行う。設定の一例として、以下が挙げられる。
（１）紙サイズ
（２）紙の厚さ
（３）紙を給紙するカセット番号
（４）プリント枚数
上記（１）の紙サイズは、プリントすべき用紙のサイズであって、いくつかの定型サイズ、またはユーザの用意する不定型サイズが設定される。画像形成装置によってプリント可能な用紙サイズが変わるが、本実施例における画像形成装置には、Ａ３〜Ａ６、Ｂ３〜Ｂ６の用紙サイズを指定できるものとする。
上記（２）の紙の厚さについても同様に、プリントすべき用紙の厚さについての設定で
ある。画像形成装置には、紙の厚さを何段階かに分類して、制御を変えるものがある。一般的には、紙が厚いと紙が曲がりにくく、滑りやすくなる。このため、画像形成装置は、紙の厚さに応じて搬送速度を抑えたり、その他の処理を変更することで、プリント品質の担保に努めている。紙の厚さはユーザがプリント時に指定するか、画像形成装置が自ら判定する。本実施例における画像形成装置は、紙の厚さによる各種制御の切替を３種類持つものとし、それぞれ「厚い」「普通」「薄い」という印刷設定とする。
上記（３）のカセット番号は、プリント時に使用する給紙カセットを指定するための情報である。画像形成装置によっては複数の給紙カセットを持ち、各々に用紙を積載することが可能なものがある。この場合、どのカセットから給紙を行うかを、ユーザが決定して画像形成装置に指示する、又は、画像形成装置自身が判断して決定する。本実施例における画像形成装置は給紙カセットを２つ保持するものとし、それぞれ「給紙口１」「給紙口２」の名称であるとした。
上記（４）のプリント枚数は、同様の印刷設定で何枚の連続プリントを行うかを設定するものである。
画像形成装置用のソフトウェアには、ほかにも様々な印刷設定が存在し得るが、画像形成装置の印刷設定について殊更に述べるのは本発明の趣旨ではないため、ここでは便宜的に上記４種類の印刷設定のみであるとする。
【００２１】
上記のような画像形成装置の制御ソフトウェアを評価する場合、プリント動作を評価するという観点では、各印刷設定の全ての組み合わせを網羅的に実施したい。
また、画像形成装置の制御ソフトウェアはプリント制御以外にも様々な制御をしており、それらの評価も必要となる。機能面に表れない、非機能要件についても評価する必要が有る。
上記のとおり、評価の作業量が膨大であるため、システムが自動的に評価を行うものであっても、一度に全ての評価を行うのは難しい。
したがって、本実施例では、評価を目的別に分類し、ひとつひとつの評価に対する作業量を減らすことを行う。本明細書では、この評価の１作業単位を、以後「評価項目」と記す。
評価リスト情報１３４には、上記の複数の評価項目を格納することができる。評価リスト情報１３４には、評価項目ごと評価の手段や、設定条件、および評価結果の成否情報を格納する。図１２は評価リスト情報１３４が格納する情報の一例である。図１２（Ａ）および図１２（Ｂ）は、プリントのシミュレーションによる評価項目が格納されている。図１２（Ｃ）はシミュレーション評価であるが、プリント動作は行わず、給紙口内の用紙を入れ替えるシミュレーションによる成否評価の情報が格納されている。図１２（Ｄ）は、静的解析による評価内容が格納されている。上記図１２（Ａ）から（Ｄ）は一例であり、評価リスト情報１３４には、他にも類似の評価項目がリスト化されて格納される。
結果判断手段１２４は、上記評価リスト情報１３４の各評価項目を実施し、評価項目内の全ての正否基準を満たすと、評価結果「ＯＫ」と判断する。
評価履歴情報１３２には、評価を終えた評価対象ソフトウェアのバージョン番号と次の情報とが関連付けられて格納される。すなわち、評価リスト情報１３４のうち、前記バージョンのソフトウェアで実施した評価リストの評価項目の識別情報と、後述の結果判断手段１２４の判断結果（評価の成否）が関連づけられて格納される。
【００２２】
評価優先度情報１３５には、評価内容決定部１１１が、評価リスト情報１３４の評価項目のいずれを実施するのかを判断するための優先度情報が格納される。
以下は優先度情報の例である。
優先度情報Ａ：更新されたソフトウェアのファイルと評価項目の対応情報
優先度情報Ｂ：更新されたソフトウェアのファイルの重要度
優先度情報Ｃ：更新されたソフトウェアのメトリクス分析結果
優先度情報Ａは、ソフトウェアのファイルと評価項目を１：１で対応づけてもよいし、
１：多、もしくは多：１で対応づけても良い。
優先度情報Ｂは、優先度情報Ａに付随する情報である。ソースコードの変更量が少なくても、更新されたファイルが重要なファイルであった場合に、必ず特定の評価項目を実行するといった目的で定めるものである。ソフトウェアのファイル毎に重要度を一律で定めても良いし、評価項目別にファイルの重要度をたがえても良い。
優先度情報Ｃも、優先度情報Ａに付随する情報である。ファイル毎にメトリクス分析を行い、結果を優先度情報として用いるものである。
【００２３】
図６（Ａ）は、優先度情報Ａの例示である。以下の、図６（Ａ）、図６（Ｂ）、図６（Ｃ）、図６（Ｄ）及び図６（Ｅ）の左欄には、ファイル情報としてのファイル名が記載されている。
図６（Ａ）は、ソフトウェアのファイルと評価項目を１：多で対応づけたものである。図中の★が対応を示す。たとえば、ｆｉｌｅ０１は評価項目ＡからＧの全てに対応付けられており、ｆｉｌｅ０２は評価項目のＡ、Ｃ、Ｇに対応づけられている。
図６（Ｂ）から図６（Ｄ）は、優先度情報Ｂの例示である。尚、以下の例では重要度の値が大きいほうをより重要であるとする。
図６（Ｂ）は、ファイル毎に重要度を定め、各評価項目に対応付けられたファイルの重要度の合計に基づき評価項目の優先度を決める場合の、優先度情報Ｂの例示である。優先度情報Ｂには、ファイル毎に重要度が数値として定義される。図６（Ｂ）の例では、ｆｉｌｅ０１の重要度値は５と定義されている。評価内容決定部１１１では、直前のバージョンからのファイルの差分情報を取得し、更新されたファイルについての重要度の合計を元に評価項目の優先度を決める。この考え方に基づき、例えばｆｉｌｅ０４とｆｉｌｅ０５とが更新されるとき、図６（Ｂ）では、評価項目Ａは両ファイルともが対応づけられており、ｆｉｌｅ０４の重要度が１、ｆｉｌｅ０５の重要度が２であるため重要度は合計３となる。評価項目Ｂ及びＣは、各々ｆｉｌｅ０５及びｆｉｌｅ０４と１つずつ対応付けられているが、重要度が異なるため、評価項目Ｂの重要度が合計２、評価項目Ｃの重要度が合計１となる。
このように、各評価項目に対する重要度の合計値が、図６（Ｂ）の「変更ファイルの重要度合計」欄のように求められ、「評価項目優先度」欄のように優先度が決定される。
【００２４】
図６（Ｃ）は、評価項目ごとに重要度を定め、各評価項目に対応付けられたファイルの重要度の合計に基づき評価項目の優先度を決める場合の、優先度情報Ｂの例示である。
優先度情報Ｂには、評価項目毎に重要度が数値として定義される。図６（Ｃ）の例では、評価項目Ａの重要度値は１と定義されている。評価内容決定部１１１では、前のバージョンから更新されたファイルについての重要度の合計を元に評価項目の優先度を決める。この考え方に基づき、たとえばｆｉｌｅ０４とｆｉｌｅ０５とが更新されるとき、評価項目Ａは両ファイルとも対応づけられているが、評価項目Ａの重要度が１であるため重要度は合計２となる。評価項目Ｅは、ｆｉｌｅ０４のみと対応付けられているが、重要度が３であるため、評価項目Ａより重要となる。
このように、各評価項目に対する重要度の合計値が、図６（Ｃ）の「変更ファイルの重要度合計」欄のように求められ、「評価項目優先度」欄のように優先度が決定される。
図６（Ｄ）は、評価項目及びファイルごとに重要度を定め、各評価項目に対応付けられたファイルの重要度の合計に基づき評価項目の優先度を決める場合の、優先度情報Ｂの例示である。
優先度情報Ｂには、評価項目及びファイルごとに重要度が数値として定義される。図６（Ｄ）の例では、ｆｉｌｅ０１の重要度値は、評価項目Ａでは５と定義され、評価項目Ｄでは２と定義されている。評価内容決定部１１１では、前のバージョンから更新されたファイルについての重要度の合計を元に評価項目の優先度を決める。この考え方に基づき、たとえばｆｉｌｅ０４とｆｉｌｅ０５とが更新されるとき、図６（Ｄ）では、評価項目Ａは両ファイルとも対応づけられているが、ｆｉｌｅ０４、ｆｉｌｅ０５ともに重要度が１
であるため重要度は合計２となる。評価項目Ｆは、ｆｉｌｅ０５のみと対応付けられているが、重要度が４であるため、評価項目Ａより重要となる。このように、各評価項目に対する重要度の合計値が、図６（Ｄ）の「変更ファイルの重要度合計」欄のように求められ、「評価項目優先度」欄のように優先度が決定される。
優先度情報Ｃについて述べる。
評価優先度情報１３５は、複雑度や凝集度、結合度といった各メトリクスに対し、許容値を定める。メトリクス解析結果が許容範囲外のファイルが有れば、優先度情報Ａで関連付けられる評価項目が評価対象の候補となる。
また、メトリクス解析結果そのものや、ひとつ前のバージョン番号のソフトウェアとのメトリクス解析結果の差分情報を評価項目への重みづけとして使用しても良い。ファイル毎にメトリクス解析を行い、解析結果を図６（Ａ）のような、ソフトウェアのファイルと評価項目との対応表への重みづけとして使用する。
【００２５】
後述する評価優先度情報１３５で、優先度を計算する際に、前記優先度情報Ｂ、Ｃを各々独立した情報として取り扱っても良いし、優先度情報Ｂ及びＣの算出結果を掛け合わせて、最終的な算出結果としてもよい。
評価優先度情報１３５には、優先度情報Ａ、Ｂ、Ｃのいずれか、またはこれらの組み合わせが格納される。また、上記例では評価項目との関連付けの対象として評価対象ソフトウェアのファイルであるとしたが、関数や、モジュールであってもよい。ここで言うモジュールとは、画像形成装置の個々の機能を構成する評価対象ソフトウェアのまとまりのことである。関連付けの対象としてモジュールを定義する場合は、評価対象ソフトウェアとモジュールとの関連付け情報を別途持つ。
【００２６】
評価内容決定部１１１は、評価指示受信手段１１４と、不具合未発見バージョンへの評価リスト決定手段１１２、不具合バージョン探索手段１１３を持つ。前記評価内容決定部１１１は、ソフトウェア評価システム１００が、評価実施部１２１で実施する評価内容を決定するもので、具体的には、ソフトウェアのバージョン番号と、評価項目を決定する機関である。該当する評価内容が複数存在する場合に、評価実施部１２１へ最優先の評価内容情報のみを渡してもよいし、優先順位をつけて複数の評価内容情報を渡してもよい。ここでは、不具合未発見バージョンへの評価リスト決定手段が決定手段に対応する。
また、評価内容決定部１１１は、評価対象のソフトウェアについて、不具合が見つかっているか否かで動作を変更する。
評価指示受信手段１１４は、実施例１で述べた通り、外部から評価指示を受ける機能を持つ。受けた指示を、不具合未発見バージョンへの評価リスト決定手段１１２へ渡す。
不具合未発見バージョンへの評価リスト決定手段１１２は、不具合が見つかっていないバージョンのソフトウェアに対して、評価リスト情報１３４内のどの評価項目を実施するかを決定する機関である。
不具合未発見バージョンへの評価リスト決定手段１１２は、評価履歴情報１３２及び、評価優先度情報１３５の情報を元に、評価リスト情報１３４の評価対象評価項目を決定して、評価実施部１２１へバージョン番号情報と、評価対象評価項目情報を渡す。
以下を判断基準とする。尚、以下の判断基準は実施例であり、本発明を制限するものではない。
優先順位１（最優先）：所定のバージョン更新回数内で未実施である
優先順位２：評価優先度情報１３５に格納される情報
優先順位１は、ソフトウェア評価システム１００の評価思想に基づく。すなわち、「所定のバージョン内に全ての評価を行い、ソフトウェア品質を担保する」というものである。そのため、未実施の評価項目がある場合には、最優先とする。
優先順位２は、ソフトウェアの更新差分と評価優先度情報１３５に格納される情報とを比較するものである。比較方法については、評価優先度情報１３５の説明時に述べたため、ここでは説明を省略する。
優先順位１で未実施の評価項目が複数存在する場合に、いずれの評価項目から評価を行うかを、優先順位２の結果から決定しても良い。
【００２７】
不具合バージョン探索手段１１３は、不具合が見つかったソフトウェアに対して、どのバージョンのソフトウェアで再評価を実施するかを決定する機関である。不具合バージョン探索手段１１３は、当該不具合が初めて発生するバージョン番号を特定するまで動作する。
不具合バージョン探索手段１１３は、評価履歴情報１３２を参照し、不具合を発見した際の評価項目について、前回不具合が見つからなかったバージョン番号情報を取得する。前回不具合が見つからなかったバージョン番号＋１から、今回不具合を見つけたバージョン番号−１までのいずれかのバージョン番号を選択する。いずれのバージョン番号を最優先とするかは、前回不具合が見つからなかったバージョン番号＋１から昇順としてもよいし、今回不具合を見つけたバージョン番号−１から降順としてよい。また、隣接する２つのバージョンについて、ソフトウェアの差分情報を取得し、最も変更量が多いバージョンを最優先としてもよい。
評価実施部１２１は、評価環境構築手段１２２、評価実行手段１２３、結果判断手段１２４から成る。評価環境構築手段１２２、結果判断手段１２４は実施例１と同じであるため説明を省略する。評価実行手段１２３は、評価リスト情報１３４から、指示された評価項目の情報を取得して実行する。
【００２８】
図７は本実施例を説明するためのフローチャートである。
ソフトウェア評価システム１００は、評価指示受信手段１１４が不図示の外部モジュールからソフトウェア評価指示を受けると、不具合未発見バージョンへの評価リスト決定手段１１２にて、実行対象の評価リスト情報を決定する（Ｓ７０２）。
このとき、不具合未発見バージョンへの評価リスト決定手段１１２は評価履歴情報１３２および評価優先度情報１３５の情報を元に、実行対象の評価リスト情報を決定する。
評価履歴情報１３２の例示を図８とする。
評価項目がＡからＧまであり、評価項目は、５バージョン内に１回行うようルール付されているとする。いま、バージョン番号１．９の評価を行う場合に、評価項目Ｂがバージョン１．４以降に未評価であることから、評価項目Ｂを最優先とし、実施対象の評価項目を記憶する領域に格納する。
評価項目Ｂ以外は、５バージョン内に試験実施済みであるため、「所定のバージョン更新回数内で未実施」の条件には当てはまらない。
次いで、評価優先度情報１３５の情報を参照する。
評価優先度情報１３５は、いま図６の（Ｄ）のような重みづけがなされているとする。また、ソフトウェアの更新ファイルがｆｉｌｅ０４、ｆｉｌｅ０５、ｆｉｌｅ０６、ｆｉｌｅ０７であったとして、優先順位を決定づける優先度の点数は図６の（Ｅ）のようになる。順に、Ｇ（１０点）、Ｂ（６点）、Ａ（５点）、Ｆ（４点）、Ｃ・Ｅ（１点）、Ｄ（０点）である。
点数が高い順から実施対象候補であるが、どこまでの評価項目を今回の実施対象とするかは以下いずれかの判断で決定する。
判断方法１：点数の上位から、所定数
判断方法２：所定点数以上
判断方法３：点数の上位から、予め定められた試験時間内に終えられる評価項目まで
判断方法３について、評価項目各々で実施する内容は所定の試験内容である。前回の試験で要した時間を記憶して使用してもよいし、試験内容からおおよその所要時間を算出する既知の技術を使用してもよい。
ソフトウェア評価システム１００は、上記１から３の判断方法のいずれを採用しても、または別の手段を採用してもよい。
本実施例は上記判断方法２で、３点以上とすると、実行対象の評価項目は、実行順に、
Ｇ、Ｂ、Ａ、Ｆとなる。ここで、評価項目Ｂは評価項目Ｇより点数が低いが、前述のとおり、１．４以降に未評価であって、既に最優先で評価を行うことを決定している。従って、評価の実行順は、Ｂ、Ｇ、Ａ、Ｆとなる。
【００２９】
不具合未発見バージョンへの評価リスト決定手段１１２は、まず評価項目Ｂと、バージョン番号１．９の情報を評価実施部１２１へ渡す。評価実施部１２１は渡された情報を元に、試験環境を構築した後に評価を行い、処理を評価内容決定部１１１へ返す（Ｓ７０３〜Ｓ７０５）。この処理は、実施例１のＳ３０２〜３０４と同様のため説明を省略する。
評価内容決定部１１１は、評価結果の成否により振る舞いを変える。評価指示受信手段１１４は、評価の結果が「ＯＫ」であれば（Ｓ７０６）、現在の状態が「不具合探索中」ではないため（Ｓ７０７）、実行対象の評価リストの未実施評価項目があるか否かを調査する。いま、実施対象の評価項目Ｂ、Ｇ、Ａ、Ｆのうち、Ｂが終了したため、次の候補はＧとなる。再び評価項目Ｇ、バージョン番号１．９の情報を評価実施部１２１へ渡し、Ｓ７０３以降のフローを行う。Ｓ７１２で、実施対象の評価項目Ｂ、Ｇ、Ａ、Ｆ全ての結果が「ＯＫ」であれば、評価終了と判断して処理を終了する。
Ｓ７０６で、評価内容決定部１１１が「ＮＧ」を受け取ると（Ｓ７０６）、不具合探索部１１３に処理を渡す。たとえば評価項目Ｇの実行中に結果「ＮＧ」となる場合には、不具合探索部１１３は、評価履歴情報１３２から、最後に評価「ＯＫ」であったバージョン番号情報を取得する。図８のとおり、最後に評価「ＯＫ」であったバージョン番号はバージョン１．５であることから、不具合はバージョン１．６から１．９までの間に発生するようになったと予測できる（Ｓ７０８、Ｓ７０９）。実施例１のＳ３０９と同様の方法で、次に評価すべきソフトウェアバージョン番号を算出すると、不具合バージョン探索手段１１３は、評価項目Ｇ、前記算出したバージョン番号を評価実施部１２１へ渡す（Ｓ７１０）。以後は実施例１と同様の方法で不具合が発生したソフトウェアのバージョン番号を算出する。最後に、Ｓ３１０と同様に報知し、処理を終える。
以上のようにして、実施例１よりも効率よく、不具合の発生したソフトウェアバージョン番号を特定することができる。
【００３０】
尚、本実施例では評価履歴情報１３２の更新を、システムのみならずユーザにも許してもよいとしている。ユーザによる「評価ＯＫ」の情報をシステムによる「評価ＯＫ」とは分けて取り扱っても良い。
たとえば、評価履歴情報１３２の情報がユーザによって「評価ＯＫ」であっても、不具合未発見バージョンへの評価リスト決定手段１１２の優先度１：所定のバージョン更新回数内で未実施であるか否かの判断では「否」として取り扱う。しかし、優先度２、３への重みづけとして取り扱い、ユーザによる「評価ＯＫ」の項目を、他の未評価の項目より優先度を下げることで、ソフトウェア評価システム１００の評価の精度向上が見込まれる。
また、実施例１でも述べた通り、ソフトウェア評価システム１００の評価設定情報１３３を、バージョン情報１０２に含めても良い。
この場合には、実施例１と同様に、バージョン管理手段１０１は、評価設定情報１３３のみの更新についてもバージョン番号を更新する。評価環境構築手段１２２は、評価設定情報１３３を、評価情報１３１からではなくバージョン管理手段１０１を介してバージョン情報１０２から取得する。不具合発生時には既に述べた処理手順で不具合の発生境界を算出することができる。
【実施例３】
【００３１】
実施例１、２は、評価環境が常に不変か、もしくはバージョン管理手段１０１でソースコード情報と共に更新管理する前提であった。
しかしながら、ソフトウェアの開発に伴い、評価環境側を変更する必要があり、かつソフトウェアのバージョン管理と、評価環境のバージョン管理を同時に行えない場合がある。
たとえば、ソフトウェアの作成者と、評価環境の作成者が異なる場合などに、ソフトウェアと評価環境のバージョン管理が非同期になり得る。
本実施例では、ソフトウェアのバージョン管理とは非同期に、評価環境側も更新される環境において、不具合の発生するバージョン番号を算出する方法について述べる。
【００３２】
図９は本実施例におけるソフトウェア評価システム１００の機能ブロック図である。
ソフトウェア評価システム１００は、バージョン管理手段１０１と、評価内容決定部１１１、評価実施部１２１、評価情報１３１から構成される。
バージョン管理手段１０１の管理するバージョン情報１０２は、実施例１、２で述べた通りであるため、説明を省略する。
評価情報１３１は、実施例１、２で述べた情報に加え、バージョン毎の評価環境情報１３５を有する。ここで、評価環境情報とは、シミュレータや各種解析ツールのような評価の実行環境の構成、設定に関する情報を意味する。また、評価対象のソースコード同様にバージョン管理手段によって管理されるものであってもよい。
また、評価設定情報１３３は、評価環境情報１３５に対する設定情報であるため、評価環境のバージョンによって設定を変更することが有る場合には、評価設定情報１３３もバージョン毎に情報を持つ。
また、評価履歴情報１３２は、実施例１、２の情報に加え、評価環境のバージョン情報を評価項目又は試験項目の結果に関連づけて記憶する。評価環境が複数のアプリケーションによって構成され、各々が独立して更新されるものである場合には、更新されうるアプリケーションのバージョン情報を全て記憶する。本実施例では説明の容易化のため、「評価環境」としてのバージョン番号を用いて説明を行う。前記評価環境のバージョン情報は、評価環境を構成するアプリケーション全てのバージョン情報と紐付いており、いずれかひとつのアプリケーションが更新されるたびに前記評価環境のバージョン番号情報も更新されるものである。ここでは、評価環境のバージョン番号が環境識別情報に対応する。
【００３３】
評価内容決定部１１１は、評価実施部１２１へ評価内容を指示するに際し、必要に応じて評価環境のバージョン情報を渡す。不具合未発見バージョンへの評価リスト決定手段１１２から評価実施部１２１へ指示する場合には、評価環境のバージョン情報は最新版を指定するか、指定しない。不具合バージョン探索手段１１３から評価実施部１２１へ指示する場合には、評価履歴情報１３２内の評価環境のバージョン情報の履歴内容に則って評価環境のバージョン情報を指定する。不具合バージョン探索手段１１３による評価環境のバージョン情報の指定方法については、別途、フローチャートを用いて詳述する。
評価実施部１２１では、評価環境構築手段１２２によって、評価項目を実施可能な環境が作成される。評価環境構築手段１２２は、指定されるバージョンの評価環境を評価環境情報１３５から取得し、かつ指定されるバージョンに則した評価設定情報１３３を取得する。評価内容決定部１１１からバージョン番号情報を指定されない場合には、最新バージョンの評価環境情報１３５および評価設定情報１３３を用いて評価環境を構築する。
このほか、図９において、図５と同番号で、かつ特記していないものに関しては、各々、実施例２と同様であるため説明を省略する。
【００３４】
図１０は本実施例における、ソフトウェア評価システム１００の動作を説明するフローチャートである。
Ｓ１００１、Ｓ１００２は実施例２のＳ７０１、Ｓ７０２と同様である。
Ｓ１００３にて、評価実施部１２１は、評価環境構築手段１２２にて、仮想環境上にソフトウェアを評価可能な環境を構築する。評価環境構築手段１２２は、評価指示受信手段１１４から渡されたバージョン番号のソフトウェア情報をバージョン管理手段１０１から取得するとともに、評価環境を評価設定情報１３３、評価環境情報１３５から取得する。評価環境のバージョン情報は、評価指示受信手段１１４からの指示がなければ最新バージョン情報を取得する。
Ｓ１００４からＳ１０１０、及びＳ１０１２は実施例２のＳ７０４からＳ７１０、Ｓ７１２と同様である。
Ｓ１０１０にて、評価実施バージョンを決定すると、不具合バージョン探索手段１１３は評価対象のソフトウェアのバージョンを決定するとともに、評価環境のバージョンをも決定する。
評価環境の更新は、ソフトウェアの更新内容と関係していることが有るため、基本的には、ソフトウェアが更新された当時の最新の評価環境を用いて評価を行う。
【００３５】
以下に評価環境のバージョン決定方法について、図１３を用いて説明する。
図１３は、本実施例の評価履歴情報１３２が管理する情報の一例である。
図１３では、評価項目Ｅについて、ソフトウェアのバージョン１．９にて不具合が発生している。当該評価実施時の、評価環境のバージョン番号は１．２である。また、図１３より、直近の評価項目Ｅの評価結果がＯＫだったとき、ソフトウェアのバージョン番号は１．５、評価環境のバージョン番号は１．０であったことが見受けられる。
不具合バージョン探索手段１１３は、ソフトウェアのバージョンに対応するバージョンの評価環境を用いて評価を行う。このため、ソフトウェアのバージョン１．６及び１．７の評価時には評価環境のバージョンは１．１、ソフトウェアのバージョン１．８の評価時には評価環境のバージョンは１．２を用いて評価を行う。
Ｓ１００８において、不具合発生バージョンを絞り込めた場合、Ｓ１０１１へと進む。
実施例２では、不具合発生バージョンを絞り込めると報知して終了したが、本実施例では、ソフトウェアと並行して評価環境が更新されるものであるため、試験結果で不具合が発生したとしても、必ずしもソフトウェアに不具合があるとは言えない。
原因は以下３種類である。
１．ソフトウェアに不具合が存在する
２．評価環境に不具合が存在する
３．ソフトウェアと評価環境のバージョンの不整合である
【００３６】
Ｓ１０１１にて、不具合発生バージョンと未発生バージョンとで評価環境のバージョン番号が同一である場合には、評価環境に変化がないにも関わらず、以前は不具合が発生せずに終えていた評価が実施出来なくなったことになる。不具合を発見したとして、Ｓ１０１２へ進み、実施例２のＳ７１２と同様の方法でユーザへ報知して、処理を終える。
Ｓ１０１１にて、不具合発生バージョンと未発生バージョンとで評価環境のバージョン番号が異なる場合には、原因は上記３種類のいずれかであるが、ここでは原因の切り分けが出来ない。このため、不具合が発生するようになったソフトウェアバージョンについて、次のような処理を行う。すなわち、評価環境のバージョン番号を、不具合が発生しなかったときと同一のバージョンになるまでに、不具合の発生有無が変化するかを、評価環境のバージョン番号をひとつずつ若返らせて評価を行う（Ｓ１０１３、Ｓ１０１４、Ｓ１０１５）。評価の結果、評価環境のバージョン番号が不具合未発生バージョンと同一になったら、Ｓ１０１１からＳ１０１２へ進む。
Ｓ１０１５にて、Ｓ１００６の評価時に不具合が発生したのと同じバージョンのソフトウェアかつ不具合が発生しない評価環境のバージョンが見付かれば、ユーザへＳ１０１４実施時のソフトウェア及び評価環境のバージョン番号情報を報知する（Ｓ１０１６）。そして処理を終える。このようにして、評価環境に基づく不具合による場合を排除することができる。
上記の方法で、ソフトウェアの開発と並行して評価環境側が更新される場合において、不具合の発生するバージョン番号を算出することができる。
【実施例４】
【００３７】
実施例１、２、３に於いて、評価履歴情報１３２を、ソフトウェア評価システム１００のみならず、ユーザが更新する手段を持たせてもよいと述べた。
評価履歴情報１３２をユーザが更新するメリットとしては、主に評価の効率化が挙げられる。ソフトウェア品質の担保の観点では、ソフトウェアのバージョン更新ごとに全ての評価項目を実施すべきである。しかしながら評価項目が多岐に渡ると、バージョン更新間隔内に、全ての評価項目を実施し終えない。そこで実施例２、３では、ソフトウェア評価システム１００が評価優先度情報１３５を持つ構成とした。実施例２、３では、この評価優先度情報１３５により、いずれの評価項目も所定のバージョン更新回数内に必ず１回は実施するとともに、その他の評価項目については、都度優先度の高い評価項目を判断して実施する方法について述べた。
ここで、ユーザによる評価結果を評価履歴情報１３２に格納出来れば、ソフトウェア評価システムは当該バージョンにおける当該評価項目をひとまず「評価済」という扱いに出来る。このため、当該評価項目の実施に必要な時間を、他の評価項目に割り当てることが出来る。
つまり、ユーザの評価結果を評価履歴情報１３２に取り込むことで、ソフトウェア評価システムは、より広範な評価を行え、ソフトウェア品質を担保できるようになると言える。
しかしながら、ユーザによる評価結果と、ソフトウェア評価システム１００による評価結果を、同一に取り扱える場合と、取り扱えない場合とが存在する。
たとえば、ユーザと、ソフトウェア評価システム１００とで、評価環境そのものや、評価環境を動作させる仮想環境が完全に同一ではないことがあり、その差異の影響で評価の結果が異なることが有る。また、ユーザが誤認識をしていたり、操作ミスで評価履歴情報１３２を誤って更新したりする可能性も有る。しかし、そのようなケースは比率的にかなり低く、たいていのケースでユーザによる評価結果と、ソフトウェア評価システム１００による評価結果が同一となる。
【００３８】
本実施例では、評価履歴情報１３２の情報を、ユーザが更新し得、かつ評価品質を担保するソフトウェア評価システム１００について述べる。
尚、本実施例では、ユーザは、評価結果が「ＯＫ」である評価項目についてのみ、評価履歴情報１３２へ登録可能とする。
ソフトウェア評価システム１００の構成は図５と同様とする。
評価履歴情報１３２は、評価履歴情報として、バージョン番号、評価リストの評価項目の識別情報、評価を実施したか否か、実施したものについては成否情報、及び評価実施者の情報（評価者情報）を関連づけて記憶する。
ここで、評価実施者は、ソフトウェア評価システム１００か否かと、後者の場合にはユーザ識別情報を記憶する。
尚、本実施例ではユーザ識別情報を記憶するが、評価実施者情報として、ソフトウェア評価システム１００か否かの情報のみを記憶してもよい。
【００３９】
図１１は本実施例のソフトウェア評価システムの動作を説明するフローチャートである。
Ｓ１１０１からＳ１１０４、Ｓ１１０６、Ｓ１１０８からＳ１１１２は、各々実施例２のＳ７０１からＳ７０４、Ｓ７０６、Ｓ７０８からＳ７１２と同一であるため、説明を省略する。
Ｓ１１０５にて、結果判断手段１２４が評価結果を評価履歴情報１３２に格納する際に、Ｓ７０５に示した情報に加えて、評価実施者情報として、ソフトウェア評価システム１００であることを示す情報を関連づけて格納する。
また、Ｓ１１０６にて、評価内容決定部１１１が評価実施部１２１から評価結果「ＮＧ」を受け取ると、不具合バージョン探索手段１１３は、評価履歴情報１３２を参照し、当該評価を過去にユーザが実施済か否かを調査する。未実施の場合は、Ｓ１１０７へ進み、不具合発生バージョンの探索を継続する。
Ｓ１１１３において、不具合が発生しないバージョンと、発生するバージョンの境界が
判明すると、不具合バージョン探索手段１１３は、当該境界における不具合が発生しないバージョンの評価実施者情報を評価履歴情報１３２から取得する。
もし、前記当該境界における不具合が発生しないバージョンの評価実施者情報がソフトウェア評価システム１００であれば、信頼性が担保されているものとして、Ｓ７１１と同様の方法で不具合発生バージョンをユーザへ報知し（Ｓ１１１８）、処理を終了する。
もし、前記当該境界における不具合が発生しないバージョンの評価実施者情報がユーザであれば、念のために、ユーザによる評価済のバージョンでも評価を実施する。このために、前記ユーザによる評価済のバージョンを、評価対象のバージョンとし（Ｓ１１１５）、再びＳ１１０３からのフローを実施する。
もし評価結果「ＮＧ」であれば、Ｓ１１０５で評価履歴情報１３２の情報を、「ユーザによる評価結果ＯＫ」を示す情報から、「システムによる評価結果ＮＧ」を示す情報に上書きする。評価結果「ＮＧ」のため、再びＳ１１０８へ進み（Ｓ１１０６）、それ以前の直近の評価結果「ＯＫ」までのバージョン間の評価を行う。
以上のようにして、ユーザによる評価結果を取り込みつつ、特別扱いすることで評価の効率化と、精度の担保を両立することが出来る。
尚、Ｓ１１０６にて、不具合が発生しており、かつ、当該バージョンかつ当該評価項目を過去にユーザが実施済である場合に、ソフトウェア評価システム１００がユーザへ警告を出力してもよい。
この場合、評価結果の差異原因が分からないため、ユーザによる評価履歴情報１３２への登録内容と、評価結果が異なるという警告にとどめる。
【符号の説明】
【００４０】
１００…ソフトウェア評価システム、１０１…バージョン管理手段、１０２…バージョン情報、１１３…不具合バージョン探索手段、１２３…評価実行手段、１２４…結果判断手段、１３２…評価履歴情報、１３４…評価リスト情報
【図１】
2019114043.tif 000003
【図２】
2019114043.tif 000004
【図３】
2019114043.tif 000005
【図４】
2019114043.tif 000006
【図５】
2019114043.tif 000007
【図６（Ａ）】
2019114043.tif 000008
【図６（Ｂ）】
2019114043.tif 000009
【図６（Ｃ）】
2019114043.tif 000010
【図６（Ｄ）】
2019114043.tif 000011
【図６（Ｅ）】
2019114043.tif 000012
【図７】
2019114043.tif 000013
【図８】
2019114043.tif 000014
【図９】
2019114043.tif 000015
【図１０】
2019114043.tif 000016
【図１１】
2019114043.tif 000017
【図１２（Ａ）】
2019114043.tif 000018
【図１２（Ｂ）】
2019114043.tif 000019
【図１２（Ｃ）】
2019114043.tif 000020
【図１２（Ｄ）】
2019114043.tif 000021
【図１３】
2019114043.tif 000022