(57)【要約】【課題】アップデート用プログラムのリリースに要する作業負担を低減可能な技術を提供する。【解決手段】リリース支援装置１は、ソフトウエアに必要とされる機能に関する機能情報５４０を記憶する機能情報記憶部５４と、機能情報５４０と、機能を実現するために必要なモジュールバージョンの識別情報とを対応付ける実現リンク情報５６１０を記憶するモジュールリンク情報記憶部５６と、アップデート用プログラムをリリースする場合に、当該アップデート用プログラムに含ませるべき機能の選択をオペレータから受け付ける選択受付部７１と、実現リンク情報５６１０を用いて、選択受付部７１が受け付けた機能の機能情報５４０と対応付けられたモジュールバージョンの識別情報を収集してリスト化するモジュールバージョン名収集部７２と、を備える。【選択図】図２０
2012208690.tif 000002
【特許請求の範囲】
【請求項１】
複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援するリリース支援装置であって、
ソフトウエアに必要とされる機能に関する機能情報を記憶する機能情報記憶部と、
ソフトウエアに必要とされる機能の前記機能情報と、当該機能を実現するために必要なモジュールバージョンの識別情報とを対応付ける実現対応情報を記憶する対応情報記憶部と、
アップデート用プログラムをリリースする場合に、前記アップデート用プログラムに含ませるべき機能の選択をオペレータから受け付ける選択受付部と、
前記実現対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を収集してリスト化するモジュールバージョン識別情報収集部と、
を備えるリリース支援装置。
【請求項２】
請求項１に記載のリリース支援装置であって、
前記アップデート用プログラムが、新しいバージョンのソフトウエアであるリリース支援装置。
【請求項３】
請求項１に記載のリリース支援装置であって、
前記アップデート用プログラムが、パッチであるリリース支援装置。
【請求項４】
請求項１から３のいずれかに記載のリリース支援装置であって、
前記ソフトウエアに必要とされる機能に、
ソフトウエアに要求される新たな機能が含まれるリリース支援装置。
【請求項５】
請求項１から４のいずれかに記載のリリース支援装置であって、
前記ソフトウエアに必要とされる機能に、
ソフトウエアに発生した障害を除去するための機能が含まれるリリース支援装置。
【請求項６】
請求項５に記載のリリース支援装置であって、
前記対応情報記憶部が、
ソフトウエアに発生した障害を除去するための機能の前記機能情報と、当該障害の原因となったモジュールバージョンの識別情報とを対応付ける原因対応情報、をさらに記憶し、
前記リリース支援装置が、
前記原因対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を特定し、さらに、特定された前記モジュールバージョンを含むソフトウエアバージョンを特定する影響範囲特定部、
をさらに備えるリリース支援装置。
【請求項７】
請求項１から６のいずれかに記載のリリース支援装置であって、
前記ソフトウエアに必要とされる機能が当該機能を実現するためのモジュールバージョンによって適切に動作するかの試験の情報を記述した試験情報を記憶する試験情報記憶部と、
前記選択受付部が受け付けた機能について行われた前記試験の前記試験情報を、前記試験情報記憶部から取得する試験情報取得部と、
をさらに備えるリリース支援装置。
【請求項８】
請求項１から７のいずれかに記載のリリース支援装置であって、
前記選択受付部が受け付けた機能の前記機能情報を、前記機能情報記憶部から取得する機能情報取得部、
をさらに備えるリリース支援装置。
【請求項９】
ＣＰＵとメモリとを備えたコンピュータによって実行されることにより、前記コンピュータを、複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援するリリース支援装置として機能させるプログラムであって、
前記ＣＰＵが前記メモリにおいて前記プログラムを実行することにより、前記コンピュータに、
ソフトウエアに必要とされる機能に関する機能情報を記憶する機能情報記憶部と、
ソフトウエアに必要とされる機能の前記機能情報と、当該機能を実現するために必要なモジュールバージョンの識別情報とを対応付ける実現対応情報を記憶する対応情報記憶部と、
アップデート用プログラムをリリースする場合に、前記アップデート用プログラムに含ませるべき機能の選択をオペレータから受け付ける選択受付部と、
前記実現対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を収集してリスト化するモジュールバージョン識別情報収集部と、
を実現させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援する技術に関する。
【背景技術】
【０００２】
ソフトウエア（アプリケーションソフトウエア）は、一般に、複数のモジュールを含んで構成される。ソフトウエアの多機能化、および機能の複雑化が進む近年においては、１個のソフトウエアが数十を超える多数のモジュールから構成される大規模なものとなっていることも珍しくない。
【０００３】
一方で、ソフトウエアは、要求される機能の追加、障害の除去等を目的として逐次更新されており、頻繁にアップデート用プログラムがリリースされている。例えば、リリース済みのソフトウエアに障害が見つかった場合等は、これを除去するための修正プログラムであるパッチがリリースされる。また、例えば、ソフトウエアが備える機能が比較的大規模に改良される場合等は、新しいバージョンのソフトウエアがリリースされる。
【０００４】
また、特に、近年においては、多様化するユーザの要求に柔軟に応じるべく、標準バージョンのソフトウエアに加え、個々のオペレータの求める機能に合わせてカスタマイズされた派生バージョンのソフトウエアがリリースされることも多く、ソフトウエアのバージョン系統は非常に複雑なものとなっている。特許文献１には、自装置にインストールされるソフトウエアのバージョンを管理するための技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１７８８８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述したとおり、近年のソフトウエアは多数のモジュールが含まれる大規模なものとなっており、ソフトウエアに含まれる各モジュールが複雑に関連し合いながら当該ソフトウエアの各機能を実現している事が多い。さらに、バージョン系統の複雑化が進むことによって、各ソフトウエアバージョンと、当該ソフトウエアバージョンに含まれるモジュールバージョンとの対応関係も入り組んだものとなっている。したがって、多数のソフトウエアバージョンのそれぞれにおいて実現される各機能と、これを実現しているモジュールバージョンとの対応関係は非常に複雑なものとなっている。
【０００７】
このような状況においては、新たな機能等を実現するためのアップデート用プログラムをリリースする場合に、当該機能を実現するために必要となるモジュールバージョンを特定する作業にも手間がかかる。
【０００８】
例えば、従来、各モジュールバージョンと、当該モジュールバージョンが実現する機能との対応関係は、例えばモジュールのソースコードを用いて管理されていた。この場合、リリースの管理者等は、機能の追加を実現するためのアップデート用プログラムをリリースするにあたって、当該機能を実現するために必要なモジュールバージョンを、各モジュールバージョンのソースコードから判断して探さなければならなかった。アップデート用プログラムには、当然の事ながら、目的とする機能を実現するために必要となるモジュールバージョンが漏れなく確実に含まれている必要があるところ、リリースの管理者等が上記の判断を誤ってしまうと、新たなアップデート用プログラムにて目的とする機能が実現されないことになり、大きな問題となってしまう。したがって、上記の判断作業は、慎重に行われる必要があり、リリースの管理者等に大きな負担を強いる作業となっていた。
【０００９】
この発明は、このような事情に鑑みてなされたものであって、アップデート用プログラムのリリースに要する作業負担を低減可能な技術を提供することを目的とする。
【課題を解決するための手段】
【００１０】
請求項１に記載の発明は、複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援するリリース支援装置であって、ソフトウエアに必要とされる機能に関する機能情報を記憶する機能情報記憶部と、ソフトウエアに必要とされる機能の前記機能情報と、当該機能を実現するために必要なモジュールバージョンの識別情報とを対応付ける実現対応情報を記憶する対応情報記憶部と、アップデート用プログラムをリリースする場合に、前記アップデート用プログラムに含ませるべき機能の選択をオペレータから受け付ける選択受付部と、前記実現対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を収集してリスト化するモジュールバージョン識別情報収集部と、を備える。
【００１１】
請求項２に記載の発明は、請求項１に記載のリリース支援装置であって、前記アップデート用プログラムが、新しいバージョンのソフトウエアである。
【００１２】
請求項３に記載の発明は、請求項１に記載のリリース支援装置であって、前記アップデート用プログラムが、パッチである。
【００１３】
請求項４に記載の発明は、請求項１から３のいずれかに記載のリリース支援装置であって、前記ソフトウエアに必要とされる機能に、ソフトウエアに要求される新たな機能が含まれる。
【００１４】
請求項５に記載の発明は、請求項１から４のいずれかに記載のリリース支援装置であって、前記ソフトウエアに必要とされる機能に、ソフトウエアに発生した障害を除去するための機能が含まれる。
【００１５】
請求項６に記載の発明は、請求項５に記載のリリース支援装置であって、前記対応情報記憶部が、ソフトウエアに発生した障害を除去するための機能の前記機能情報と、当該障害の原因となったモジュールバージョンの識別情報とを対応付ける原因対応情報、をさらに記憶し、前記リリース支援装置が、前記原因対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を特定し、さらに、特定された前記モジュールバージョンを含むソフトウエアバージョンを特定する影響範囲特定部、をさらに備える。
【００１６】
請求項７に記載の発明は、請求項１から６のいずれかに記載のリリース支援装置であって、前記ソフトウエアに必要とされる機能が当該機能を実現するためのモジュールバージョンによって適切に動作するかの試験の情報を記述した試験情報を記憶する試験情報記憶部と、前記選択受付部が受け付けた機能について行われた前記試験の前記試験情報を、前記試験情報記憶部から取得する試験情報取得部と、をさらに備える。
【００１７】
請求項８に記載の発明は、請求項１から７のいずれかに記載のリリース支援装置であって、前記選択受付部が受け付けた機能の前記機能情報を、前記機能情報記憶部から取得する機能情報取得部、をさらに備える。
【００１８】
請求項９に記載の発明は、ＣＰＵとメモリとを備えたコンピュータによって実行されることにより、前記コンピュータを、複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援するリリース支援装置として機能させるプログラムであって、前記ＣＰＵが前記メモリにおいて前記プログラムを実行することにより、前記コンピュータに、ソフトウエアに必要とされる機能に関する機能情報を記憶する機能情報記憶部と、ソフトウエアに必要とされる機能の前記機能情報と、当該機能を実現するために必要なモジュールバージョンの識別情報とを対応付ける実現対応情報を記憶する対応情報記憶部と、アップデート用プログラムをリリースする場合に、前記アップデート用プログラムに含ませるべき機能の選択をオペレータから受け付ける選択受付部と、前記実現対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を収集してリスト化するモジュールバージョン識別情報収集部と、を実現させる。
【発明の効果】
【００１９】
請求項１、９に記載の発明によると、アップデート用プログラムをリリースする場合に、オペレータが当該アップデート用プログラムに含ませたい機能を選択してリリース支援装置に入力すると、リリース支援装置が、当該機能を実現するために必要なモジュールバージョンの識別情報をリスト化してくれるので、オペレータは、アップデート用プログラムに含ませるべきモジュールバージョンを一目で把握することができる。したがって、アップデート用プログラムのリリースにおけるオペレータの作業負担が大幅に低減される。
【００２０】
請求項２に記載の発明によると、新しいバージョンのソフトウエアをリリースする場合におけるオペレータの作業負担を低減することができる。
【００２１】
請求項３に記載の発明によると、パッチをリリースする場合におけるオペレータの作業負担を低減することができる。
【００２２】
請求項４に記載の発明によると、ソフトウエアに要求される新たな機能を実現するためのアップデート用プログラムをリリースする場合において、オペレータの作業負担を低減することができる。
【００２３】
請求項５に記載の発明によると、ソフトウエアに発生した障害を除去するための機能を実現するためのアップデート用プログラムをリリースする場合において、オペレータの作業負担を低減することができる。
【００２４】
請求項６に記載の発明によると、ソフトウエアに発生した障害を除去するための機能を実現するためのアップデート用プログラムをリリースする場合に、当該障害の原因となったモジュールバージョンを含むソフトウエアバージョンを特定することができる。この構成によると、オペレータは、アップデート用プログラムをリリースするべき範囲を正確かつ確実に把握することができる。
【００２５】
請求項７に記載の発明によると、アップデート用プログラムをリリースする場合に、オペレータが当該アップデート用プログラムに含ませたい機能を選択してリリース支援装置に入力すると、リリース支援装置が、当該機能について行われた試験の情報を取得する。したがって、オペレータは、アップデート用プログラムに含ませる機能について行われた試験の情報を簡易に取得することができる。
【００２６】
請求項８に記載の発明によると、アップデート用プログラムをリリースする場合に、オペレータが当該アップデート用プログラムに含ませたい機能を選択してリリース支援装置に入力すると、リリース支援装置が、当該機能に関する機能情報を取得する。したがって、オペレータは、アップデート用プログラムに含ませる機能に関する情報を簡易に取得することができる。
【図面の簡単な説明】
【００２７】
【図１】ソフトウエア管理システムの概略構成を示す図である。
【図２】リリース支援装置を構成するコンピュータのハードウェア構成例を示す図である。
【図３】リリース支援装置にて扱われるソフトウエアの一例を説明するための図である。
【図４】データベースの構成を模式的に示す図である。
【図５】データベースに蓄積される情報の構成を説明するための図である。
【図６】データベースに蓄積される情報の構成を説明するための図である。
【図７】ソフトウエア情報の構成例を模式的に示す図である。
【図８】モジュール情報の構成例を模式的に示す図である。
【図９】ソフトウエアリンク情報の構成例を模式的に示す図である。
【図１０】要求情報の構成例を模式的に示す図である。
【図１１】障害情報の構成例を模式的に示す図である。
【図１２】試験情報の構成例を模式的に示す図である。
【図１３】実現リンク情報の構成例を模式的に示す図である。
【図１４】原因リンク情報の構成例を模式的に示す図である。
【図１５】対応モジュールの登録画面の構成例を示す図である。
【図１６】機能とモジュールとの対応関係を示す一覧画面の構成例を示す図である。
【図１７】試験情報の登録画面の構成例を示す図である。
【図１８】リリース支援装置の機能構成を示すブロック図である。
【図１９】新しいソフトウエアバージョンのリリース支援に関するする処理の流れを示す図である。
【図２０】新しいソフトウエアバージョンのリリース支援に関するする処理の流れを説明するための模式図である。
【図２１】新しいパッチのリリース支援に関するする処理の流れを示す図である。
【図２２】新しいパッチのリリース支援に関するする処理の流れを説明するための模式図である。
【図２３】新しいパッチのリリース支援に関するする処理の流れを説明するための模式図である。
【発明を実施するための形態】
【００２８】
以下、添付の図面を参照しながら、本発明の実施形態について説明する。以下の実施形態は、本発明を具体化した一例であり、本発明の技術的範囲を限定する事例ではない。
【００２９】
＜１．開発管理システムの全体構成＞
本発明の実施形態に係る、ソフトウエアの開発管理システム１００の構成について、図１を参照しながら説明する。図１は、開発管理システム１００の概略構成を示す図である。
【００３０】
開発管理システム１００は、ソフトウエア（具体的には、コンピュータに実行させるプログラムであり、装置、機器に内蔵し、その動作を制御するプログラムを含む。）の開発を管理、支援するシステムであり、リリース支援装置１と、複数個の端末装置２とを、ＬＡＮ（Local Area Network）、インターネット等のネットワーク３を介して接続した構成を備えている。
【００３１】
＜リリース支援装置１＞
リリース支援装置１は、複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援する装置であり、コンピュータ１０により構成される。図２には、リリース支援装置１を構成するコンピュータ１０のハードウェア構成例が示されている。
【００３２】
コンピュータ１０は、演算処理を行うＣＰＵ１１、基本プログラムを記憶するＲＯＭ１２、各種情報を記憶するＲＡＭ１３を、バスライン２０に接続した一般的なコンピュータシステムにより構成される。バスライン２０にはさらに、ＣＰＵ１１の作業領域（ワーク部分）となるメモリ１４、情報記憶を行う固定ディスク１５、各種情報の表示を行う表示部１６、マウスやキーボードで構成され、オペレータからの入力を受け付ける入力部１７、コンピュータ読み取り可能な電子媒体９０１（例えば、光ディスク、磁気ディスク、光磁気ディスク等）からの情報の読み取り、および、電子媒体９０１への情報の書き込みを行う読取／書込装置１８が接続される。さらに、バスライン２０には、ネットワーク３を介して端末装置２と通信を行う通信部１９が、インターフェイス（Ｉ／Ｆ）を介する等して接続される。
【００３３】
コンピュータ１０が備える読取／書込装置１８を介して電子媒体９０１から読み出された（あるいは、通信部１９を介してダウンロードされた）プログラム９０２が固定ディスク１５に記憶され、さらにプログラム９０２がＲＡＭ１３にコピーされるとともにＣＰＵ１１がＲＡＭ１３内のプログラム９０２に従ってメモリ１４において演算処理を実行することによって、コンピュータ１０において、リリース支援装置１としての各種の機能が実現される。
【００３４】
＜端末装置２＞
端末装置２は、リリース支援装置１とネットワーク３を介して接続された装置であり、リリース支援装置１に対してソフトウエアの開発管理に関する情報の登録を行うことができる。また、リリース支援装置１に対して情報の閲覧を請求するとともに、リリース支援装置１から情報の提供を受けることができる。端末装置２は、コンピュータにより構成される。端末装置２を構成するコンピュータのハードウェア構成は、上述したコンピュータ１０と同様であるので、その詳細な説明を省略する。
【００３５】
＜２．ソフトウエア＞
リリース支援装置１は、上述したとおり、複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援する。リリース支援装置１について具体的に説明する前に、リリース支援装置１にて扱われるソフトウエアについて、図３を参照しながら説明する。図３は、リリース支援装置１にて扱われるソフトウエアの一例を説明するための図である。
【００３６】
リリース支援装置１にて扱われるソフトウエアは、例えば、基板処理装置９の動作を制御するためのソフトウエア９００である。基板処理装置９は、半導体ウエハなどの基板Ｗに薬液処理、純水処理、乾燥処理を行う装置であり、基板Ｗを基板処理装置９内に取り込み、また払い出しする載置台９１と、基板Ｗを処理する複数の処理部９２と、基板Ｗを保持して載置台９１と処理部９２との間を移動して基板Ｗを搬送する搬送機構９３とを備える。基板処理装置９は、さらに、コンピュータ９０を備える。ソフトウエア９００がこのコンピュータ９０において実行されることにより、基板処理装置９の動作を制御する制御部が構成される。
【００３７】
図３の下段には、ソフトウエア９００の構成が模式的に示されている。ソフトウエア９００には、当該ソフトウエア９００を識別するための情報として、ソフトウエアバージョン名が付与される。図示の例では、ソフトウエア名「FCK」にバージョン番号「3.2」を付したソフトウエアバージョン名「FCK-3.2」が付与されている。
【００３８】
また、ソフトウエア９００は、複数個のモジュールを備える。図示されたソフトウエア９００においては、基板処理装置９の全体の制御を司るモジュール（モジュール名「Sys」）、警報に関するモジュール（モジュール名「Arm」）、操作画面の表示構成に関するモジュール（モジュール名「Gui」）等を備える。
【００３９】
さらに、各モジュールには、当該モジュールを識別するための情報としてモジュールバージョン名が付与される。図示の例では、例えば、モジュール名「Sys」にバージョン番号「2.2」を付したモジュールバージョン名「Sys2.2」等が付与されている。
【００４０】
なお、ソフトウエアバージョン名「FCK-3.2」や、モジュールバージョン名「Sys2.2」は、ソフトウエア、およびモジュールを識別する情報の一例であって、任意に決められるものである。
【００４１】
＜３．データベース５０＞
リリース支援装置１の固定ディスク１５には、ソフトウエアの開発管理に関する情報を登録・蓄積するデータベース（ＤＢ）５０が構築されている（図２参照）。データベース５０の構成について、図４〜図１４を参照しながら説明する。図４は、データベース５０の構成を模式的に示す図である。図５、図６は、データベース５０に蓄積される情報の構成を説明するための図である。図７〜図１４は、データベース５０に記憶される各情報の構成例を示す図である。
【００４２】
データベース５０は、ソフトウエア情報記憶部５１と、モジュール情報記憶部５２と、ソフトウエアリンク情報記憶部５３とを備える。さらに、データベース５０は、機能情報記憶部５４と、試験情報記憶部５５と、モジュールリンク情報記憶部５６とを備える。リリース支援装置１の入力部１７を介してオペレータから入力された情報、あるいは、ネットワーク３を介して端末装置２から受信された情報は、それぞれ所定の記憶部に蓄積されることになる。すなわち、オペレータは、リリース支援装置１の入力部１７、あるいは、端末装置２の入力部を介してデータベース５０に各種の情報を登録することができる。
【００４３】
＜ソフトウエア情報記憶部５１＞
ソフトウエア情報記憶部５１には、ソフトウエアバージョンに関する情報（ソフトウエア情報５１０）が記憶される。ソフトウエア情報５１０は、ソフトウエアの更新ごとに蓄積される。図７は、ソフトウエア情報５１０の構成例を模式的に示す図である。ソフトウエア情報５１０には、例えば、「ソフトウエアバージョン名」、「登録日」、「リリース」、「ノート」等が含まれる。「ソフトウエアバージョン名」は、上述の通り、ソフトウエアを識別する情報である。また、「登録日」は、当該ソフトウエアがデータベース５０に登録された年月日である。また、「リリース」は当該ソフトウエアをリリースした年月日である。また、「ノート」は当該ソフトウエアの更新の経緯等に関する覚書である。ソフトウエア情報５１０には、さらに、ソフトウエア名、親となるソフトウエアバージョン名等が含まれてもよい。
【００４４】
＜モジュール情報記憶部５２＞
モジュール情報記憶部５２には、モジュールバージョンに関する情報（モジュール情報５２０）が記憶される。モジュール情報５２０は、ソフトウエアの構成部品であるモジュールの更新ごとに蓄積される。図８は、モジュール情報５２０の構成例を模式的に示す図である。モジュール情報５２０には、例えば、「モジュールバージョン名」、「モジュール名」、「登録日」、「ノート」等が含まれる。「モジュールバージョン名」は、上述の通り、モジュールを識別する情報である。また、「登録日」は、当該モジュールがデータベース５０に登録された年月日である。また、「ノート」は当該モジュールの更新の経緯等に関する覚書である。モジュール情報５２０には、さらに、親となるモジュールバージョン名等が含まれてもよい。
【００４５】
＜ソフトウエアリンク情報記憶部５３＞
ソフトウエアリンク情報記憶部５３には、ソフトウエア情報５１０とモジュール情報５２０とをリンクする情報（ソフトウエアリンク情報５３０）が記憶される。
【００４６】
ソフトウエアリンク情報５３０は、具体的には、ソフトウエアバージョンと、そのソフトウエアバージョンを構成するモジュールバージョンとをリンクさせる情報であり、例えば図９に例示するように、ソフトウエアバージョンのソフトウエアバージョン名と、そのソフトウエアバージョンを構成するモジュールバージョンのモジュールバージョン名とが対応付けられたテーブル（ソフトウエアリンクテーブル）の形で保持される。なお、ソフトウエアにおいては、一つのソフトウエアバージョンが複数個のモジュールバージョンによって構成される一方、一つのモジュールバージョンが複数個のソフトウエアバージョンに組み込まれている場合がある。したがって、ソフトウエア情報５１０とモジュール情報５２０との関係は、いわゆる多対多となりうる。
【００４７】
＜機能情報記憶部５４＞
機能情報記憶部５４には、ソフトウエアに必要とされる機能に関する情報（機能情報５４０）が記憶される。ここで、ソフトウエアに必要とされる機能は、二種類に類型化できる。
【００４８】
第１の類型に係る機能は、ソフトウエアに要求される新たな機能である。機能情報記憶部５４には、この類の機能に関する機能情報５４０として、要求に関する情報（要求情報５４０ａが記憶される。要求情報５４０ａには、例えば図１０に例示するように、「要求番号」、「要求内容」、「ステータス」、「発生日時」等が含まれる。「要求番号」は、登録された要求を識別するための情報であり、要求の登録の際に付与される。「要求内容」は、要求の内容を示す情報である。「ステータス」は、要求に対する対応状況を示す情報である。「ステータス」は、例えば、要求された機能を実現するためのモジュールの作成が開始されていない場合は「未対応」等とされ、作成中の間は「対応中」、あるいは「○年○月○日完成予定」等とされ、要求された機能を実現するためのモジュールが完成し、ソースコードが登録された場合は「作成済み」等とされる。また、当該機能を実現したソフトウエアバージョン（あるいは、パッチ）のリリースが完了すると、「リリース済み」等とされる。「発生日時」は、当該要求がデータベース５０に登録された年月日である。
【００４９】
第２の類型に係る機能は、ソフトウエアに発生した障害を除去するための機能である。機能情報記憶部５４には、この類の機能に関する機能情報５４０として、障害に関する情報（障害情報５４０ｂ）が記憶される。障害情報５４０ｂには、例えば図１１に例示するように、「障害番号」、「障害内容」、「ステータス」、「発生日時」等が含まれる。「障害番号」は、登録された障害を識別するための情報であり、障害の登録の際に付与される。「障害内容」は、障害の内容を示す情報である。「ステータス」は、障害に対する対応状況を示す情報であり、要求情報５４０ａにおける「ステータス」と同様である。「発生日時」は当該障害がデータベース５０に登録された年月日である。障害情報５４０ｂとして、さらに、障害の発生が確認されたソフトウエアバージョン名が保持されてもよい。
【００５０】
＜試験情報記憶部５５＞
試験情報記憶部５５には、試験情報５５０が記憶される。試験情報５５０とは、ソフトウエアに実装するに先だって、ソフトウエアに必要とされる各機能が、当該機能を実現するための各モジュールによって適切に動作するかのテスト（試験）に関連する情報である。試験情報５５０には、例えば図１２に例示するように、「試験番号」、「試験内容」、「試験結果」、「要求・障害番号」、「登録日」等が含まれる。「試験番号」は、登録された試験情報５５０を識別するための情報であり、試験情報５５０の登録の際に付与される。「試験内容」は、行われた試験の内容・方法を示す情報である。「試験結果」は、試験の結果を示す情報である。「要求・障害番号」は、当該試験が対象とする機能（ソフトウエアに必要とされる機能）を特定するための情報であり、具体的には、例えば、当該機能に関連する機能情報５４０に付与された要求番号、あるいは、障害番号である。「登録日」は当該試験情報５５０がデータベース５０に登録された年月日である。
【００５１】
＜モジュールリンク情報記憶部５６＞
モジュールリンク情報記憶部５６には、モジュール情報５２０と機能情報５４０とをリンクする情報（モジュールリンク情報５６０）が記憶される。モジュールリンク情報５６０には、ソフトウエアに必要とされる機能と、その機能を実現するモジュールバージョンとをリンクさせる情報（実現リンク情報５６１０）（図５参照）と、ソフトウエアに発生した障害と、その障害の原因となったモジュールバージョンとをリンクさせる情報（原因リンク情報５６２０）（図６参照）とが含まれる。
【００５２】
実現リンク情報５６１０は、例えば図１３に例示するように、ソフトウエアに必要とされる機能の要求番号、あるいは、障害番号と、当該機能を実現するモジュールバージョンのモジュールバージョン名とが対応付けられたテーブル（モジュールリンクテーブル）の形で保持される。なお、ソフトウエアにおいては、一つの機能は、複数個のモジュールバージョンによって実現される場合がある。一方、一つのモジュールバージョンが複数種類の機能の実現に必要とされる場合もある。したがって、機能とモジュールバージョンとの関係は、いわゆる多対多となりうる。なお、実現リンク情報５６１０として、ソフトウエアに要求される新たな機能と、当該機能を実現するモジュールバージョンとを対応付ける第１のテーブルと、ソフトウエアに発生した障害を除去するための機能と、当該機能を実現するモジュールバージョンとを対応付ける第２のテーブルとが別々に保持されてもよい。
【００５３】
一方、原因リンク情報５６２０は、例えば図１４に例示するように、ソフトウエアに発生した障害の障害番号と、当該障害の原因となったモジュールバージョンのモジュールバージョン名とが対応付けられたテーブル（モジュールリンクテーブル）の形で保持される。なお、ソフトウエアにおいては、一つの障害の原因が、複数個のモジュールバージョンにまたがっている場合がある。一方、一つのモジュールバージョンが複数種類の障害の原因となっている場合もある。したがって、機能とモジュールバージョンとの関係は、いわゆる多対多となりうる。
【００５４】
＜４．登録の流れ＞
ここで、機能情報５４０、試験情報５５０、および、モジュールリンク情報５６０の登録に係る処理の流れについて説明する。
【００５５】
ソフトウエアに必要とされる機能が発生すると、オペレータ（例えば、ソフトウエアの設計を担当する者）が、当該機能に関する機能情報５４０を、入力部１７（あるいは、端末装置２の入力部でもよい。以下においても同様。）を介して登録する。具体的には、オペレータは、ソフトウエアに新たな機能の要求が発生した場合は、要求情報５４０ａ（具体的には、「要求番号」、「要求内容」、「ステータス」、「発生日時」等の各項目）を登録する。また、オペレータは、ソフトウエアに障害が発生し、これを除去するための機能が必要となった場合は、障害情報５４０ｂ（具体的には、「障害番号」、「障害内容」、「ステータス」、「発生日時」等の各項目）を登録する。オペレータから登録された各情報は、機能情報記憶部５４に記憶される。
【００５６】
機能情報５４０が登録されると、オペレータ（例えば、ソフトウエアの設計を担当する者）は、入力部１７を介して、機能情報記憶部５４に登録された各機能を実現するために必要なモジュール（対応モジュール）を登録する。図１５には、対応モジュールの登録操作を支援するための画面（登録画面）６１の構成例が示されている。ここに示されるように、登録画面６１においては、ソフトウエアに含まれるモジュール名の一覧が表示される。オペレータは、機能情報記憶部５４に登録された機能（具体的には、機能情報５４０）のいずれかを選択し、当該機能を実現するために必要なモジュールを選択入力する。モジュールの選択入力は、例えば、当該モジュール名のチェックボックスの位置で、入力部１７のマウスを用いてクリック操作することによって行うことができる。選択入力が行われると当該モジュール名のチェックボックスにチェックマークが表示され、当該モジュールが、選択されている機能の対応モジュールとして登録される。選択されている機能を実現するために必要なモジュールが複数個存在する場合は、オペレータは、各モジュールについて上記の操作を繰り返して行うことによって、当該複数個のモジュールの全てを対応モジュールとして登録する。なお、登録画面６１においては、選択した機能の「ステータス」も入力可能としてもよい。ここで登録されたステータスの情報は、機能情報記憶部５４に記憶される機能情報５４０に反映されることになる。
【００５７】
機能情報記憶部５４に登録された各機能とモジュールとの関係は、オペレータからの指示に応じて、表示部１６に一覧表示可能とされてもよい。図１６には、機能情報記憶部５４に登録された各機能とモジュールとの関係を示す一覧画面６２の構成例が示されている。ここに示されるように、一覧画面６２においては、横軸にモジュール名の一覧が、縦軸に機能を示す情報（例えば、機能情報５４０として登録されている「要求内容」、あるいは、「障害内容」）の一覧がそれぞれ表示される。そして、あるモジュールがある機能の対応モジュールである場合は、当該モジュールの欄と当該機能の欄とが交差した領域に、マーク（例えば丸印）が表示される。なお、一覧画面６２において、各機能の「ステータス」に応じてその機能を示す情報の表示態様（例えば、文字色等）を変えてもよい。例えば、「対応中」の機能は赤色で表示する等してもよい。また、一覧画面６２において、各対応モジュールの作成状況に応じてマークの表示態様（例えば、丸印の色等）を変えてもよい。例えば、ある対応モジュールにおいて機能を実現するためのモジュールバージョンの作成が完了していない場合は丸印を赤色で、完了している場合は丸印を青色で、それぞれ表示する等してもよい。
【００５８】
続いて、オペレータ（例えば、モジュールの構成管理を担当する者）は、入力部１７を介して、実現リンク情報５６１０を登録する。具体的には、オペレータは、機能情報記憶部５４に登録された機能のいずれかを選択し、当該機能について登録された対応モジュールのそれぞれについて、当該機能を実現するための新たなモジュールバージョンのモジュールバージョン名を、当該機能の要求番号、あるいは、障害番号と対応付けて登録する。当該登録された情報は、実現リンク情報５６１０としてモジュールリンク情報記憶部５６に記憶される。
【００５９】
また、オペレータ（例えば、モジュールの構成管理を担当する者）は、入力部１７を介して、原因リンク情報５６２０を登録する。具体的には、オペレータは、機能情報記憶部５４に登録された機能（ただし、障害を除去するための機能）のいずれかを選択し、当該機能について登録された対応モジュールのそれぞれについて、当該機能において除去対象とされている障害の原因となったモジュールバージョン（すなわち、障害が混入しているモジュールバージョン）のモジュールバージョン名を、当該機能の障害番号と対応付けて登録する。当該登録された情報は、原因リンク情報５６２０としてモジュールリンク情報記憶部５６に記憶される。
【００６０】
一方、オペレータ（例えば、ソフトウエアの構成管理を担当する者）は、機能情報記憶部５４に登録された機能を実現するための各モジュールバージョンの作成が進むと、当該モジュールバージョンによって当該機能が適切に動作するかのテスト（試験）を行う。試験を行った場合、オペレータは、当該試験に関する試験情報５５０を、入力部１７を介して登録する。図１７には、試験情報５５０の登録操作を支援するための画面（登録画面）６３の構成例が示されている。ここに示されるように、登録画面６３には、試験番号、試験内容、試験結果、登録日等の入力をそれぞれ受け付ける入力ボックスと、試験の対象となった機能の要求番号、あるいは障害番号の入力を受け付ける入力ボックスとが表示される。オペレータは、各入力ボックスに該当する情報を記入し、登録の指示を入力する。これによって、当該項目に入力された試験情報５５０として試験情報記憶部５５に記憶される。
【００６１】
＜５．リリース支援装置１の機能構成＞
リリース支援装置１の機能構成について、図１８を参照しながら説明する。図１８は、リリース支援装置１の機能構成を示すブロック図である。
【００６２】
リリース支援装置１は、アップデート用プログラム（具体的には、新しいバージョンのソフトウエア、リリース済みのソフトウエアに修正を施すためのパッチ等）のリリースを支援する機能として、選択受付部７１、モジュールバージョン名収集部７２、試験情報取得部７３、リリースノート作成部７４、リリース管理部７５、および、影響範囲特定部７６を備える。これらの各機能部は、コンピュータ１０にプログラム９０２を実行させることにより実現されてもよいし、専用のハードウェアを含んで実現されてもよい。
【００６３】
選択受付部７１は、アップデート用プログラムをリリースする場合に、当該アップデート用プログラムに含ませるべき機能の選択をオペレータから受け付ける。具体的には、オペレータがアップデート用プログラムに含ませたい機能を特定するための情報（例えば、要求番号、あるいは、障害番号）を、入力部１７（あるいは、端末装置２の入力部）を介して入力すると、選択受付部７１は、当該入力された機能を受け付ける。
【００６４】
モジュールバージョン名収集部７２は、リリース予定のアップデート用プログラムに含ませるべきモジュールバージョンのリスト（以下「モジュールバージョン名リスト７２０」という）を生成する。具体的には、モジュールバージョン名収集部７２は、モジュールリンク情報記憶部５６に記憶された実現リンク情報５６１０を用いて、選択受付部７１が受け付けた各機能と対応付けられたモジュールバージョン名（すなわち、当該機能を実現するために必要なモジュールバージョンのモジュールバージョン名）を収集してリスト化する。ここでリストアップされたモジュールバージョンは、リリース予定のアップデート用プログラムに含ませるべきモジュールバージョンとなっている。
【００６５】
試験情報取得部７３は、選択受付部７１が受け付けた各機能について行われた試験の試験情報５５０を試験情報記憶部５５から読み出して、試験情報群７３０として取得する。試験情報群７３０に含まれる各試験情報５５０は、リリース予定のアップデート用プログラムにて実現される予定の各機能について行われた試験の試験情報５５０となっている。
【００６６】
リリースノート作成部７４は、選択受付部７１が受け付けた各機能の機能情報５４０を機能情報記憶部５４から読み出して、これをまとめたファイル（リリースノート７４０）を作成する。ここで生成されるリリースノート７４０には、リリース予定のアップデート用プログラムにて実現される予定の各機能に関する情報（具体的には、要求内容、あるいは、障害内容、発生日時等）が含まれることになる。
【００６７】
リリース管理部７５は、上記の各部がそれぞれ取得した情報を取得して、これをまとめたファイル（管理ファイル７５０）を作成する。すなわち、リリース管理部７５は、モジュールバージョン名収集部７２から取得したモジュールバージョン名リスト７２０、試験情報取得部７３から取得した試験情報群７３０、リリースノート作成部７４から取得したリリースノート７４０をそれぞれ含んだ管理ファイル７５０を作成する。また、リリース管理部７５は、作成した管理ファイル７５０を、表示部１６（あるいは、端末装置２の表示部）に表示させる。
【００６８】
影響範囲特定部７６は、新しいパッチをリリースする場合に、当該パッチをリリースすべき範囲（すなわち、障害の影響範囲）を特定する。具体的には、影響範囲特定部７６は、モジュールリンク情報記憶部５６に記憶された原因リンク情報５６２０を用いて、選択受付部７１が受け付けた各機能と対応付けられたモジュールバージョン名（すなわち、当該機能によって除去される障害の、原因となったモジュールバージョンのモジュールバージョン名）を特定する。さらに、特定されたモジュールバージョンを含むソフトウエアバージョンのソフトウエアバージョン名を、ソフトウエアリンク情報記憶部５３に記憶されたソフトウエアリンク情報５３０を用いて特定する。ここで特定されたソフトウエアバージョンは、障害（リリース予定のパッチにて除去される障害）が影響するソフトウエア、すなわち、当該パッチをリリースすべきソフトウエアとなっている。
【００６９】
＜６．リリース支援装置１における処理の流れ＞
続いて、リリース支援装置１において実行される処理の流れについて説明する。
【００７０】
＜６−１．ソフトウエアのリリース支援＞
新しいソフトウエアバージョンのリリース支援に関するする処理の流れについて、図１９、図２０を参照しながら説明する。図１９は、当該処理の流れを示す図である。図２０は、当該処理を説明するための模式図である。
【００７１】
まず、選択受付部７１が、リリース予定のソフトウエアバージョン（以下、「対象ソフトウエアバージョン」という）に含ませるべき機能の選択をオペレータから受け付ける（ステップＳ１１）。すなわち、オペレータが対象ソフトウエアバージョンに含ませたい機能を特定するための情報（例えば、要求番号、あるいは、障害番号）を、入力部１７（あるいは、端末装置２の入力部）を介して入力すると、選択受付部７１は、当該入力された機能を受け付ける。ただし、オペレータは、対象ソフトウエアバージョンに含ませたい機能を複数個選択することができる。図２０には、「要求番号Ｒ３」「障害番号Ｆ１」「障害番号Ｆ２」に係る３つの機能が対象ソフトウエアバージョンに含ませるべき機能として選択された様子が示されている。
【００７２】
１以上の機能の選択が受け付けられると、リリース管理部７５が、対象ソフトウエアバージョンのソフトウエアバージョン名を決定する（ステップＳ１２）。具体的には、現在リリース完了している最新のソフトウエアバージョンのソフトウエアバージョン名を参照し、これに基づいて対象ソフトウエアバージョンのソフトウエアバージョン名を決定する。例えば、現在リリース完了している最新のソフトウエアバージョンのソフトウエアバージョン名が「FCK-3.4」であれば、対象ソフトウエアバージョンのソフトウエアバージョン名を「FCK-3.5」に決定する。なお、ソフトウエアに複数の派生バージョンが存在している場合、ステップＳ１１で受け付けられた機能と関連のある派生バージョン（例えば、選択された機能の一部を実現している派生バージョン、選択された機能を実現するために前提となる機能を実現している派生バージョン等）を一つ選択し、当該派生バージョンのバージョン系統において、現在リリース完了している最新のソフトウエアバージョンのソフトウエアバージョン名を参照して対象ソフトウエアバージョンのソフトウエアバージョン名を決定する。
【００７３】
続いて、モジュールバージョン名収集部７２が、モジュールリンク情報記憶部５６に記憶された実現リンク情報５６１０を用いて、ステップＳ１１で受け付けられた各機能と対応付けられたモジュールバージョン名を収集して、これらをリスト化したモジュールバージョン名リスト７２０を生成する（ステップＳ１３）。ここでリストアップされたモジュールバージョンは、対象ソフトウエアバージョンに含ませるべきモジュールバージョンとなっている。
【００７４】
続いて、試験情報取得部７３が、ステップＳ１１で受け付けられた各機能について行われた試験の試験情報５５０を試験情報記憶部５５から読み出して試験情報群７３０として取得する（ステップＳ１４）。ここで読み出された各試験情報５５０は、対象ソフトウエアバージョンにて実現される予定の各機能について行われた試験の試験情報５５０となっている。
【００７５】
続いて、リリースノート作成部７４が、ステップＳ１１で受け付けられた各機能の機能情報５４０を機能情報記憶部５４から読み出して、リリースノート７４０を作成する（ステップＳ１５）。ここで生成されるリリースノート７４０には、対象ソフトウエアバージョンにて実現される予定の各機能に関する情報が含まれることになる。
【００７６】
続いて、リリース管理部７５が、管理ファイル７５０を作成する（ステップＳ１６）。具体的には、ステップＳ１３で生成されたモジュールバージョン名リスト７２０と、ステップＳ１４で取得された試験情報群７３０と、ステップＳ１５で作成されたリリースノート７４０とを含めた管理ファイル７５０を作成し、当該管理ファイル７５０をステップＳ１２で決定されたソフトウエアバージョン名と対応付ける。さらに、作成した管理ファイル７５０を、表示部１６（あるいは、端末装置２の表示部）に表示させる。
【００７７】
＜６−２．パッチのリリース支援＞
新しいパッチのリリース支援に関するする処理の流れについて図２１〜図２３を参照しながら説明する。図２１は、当該処理の流れを示す図である。図２２、図２３は、当該処理を説明するための模式図である。
【００７８】
まず、選択受付部７１が、リリース予定のパッチ（以下、「対象パッチ」という）に含ませるべき機能の選択をオペレータから受け付ける（ステップＳ２１）。すなわち、オペレータが対象パッチに含ませたい機能を特定するための情報（例えば、要求番号、あるいは、障害番号）を、入力部１７（あるいは、端末装置２の入力部）を介して入力すると、選択受付部７１は、当該入力された機能を受け付ける。ただし、オペレータは、対象パッチに含ませたい機能を複数個選択することができる。図２２には、「障害番号Ｆ１」に係る機能が対象パッチに含ませるべき機能として選択された様子が示されている。
【００７９】
１以上の機能の選択が受け付けられると、影響範囲特定部７６が、モジュールリンク情報記憶部５６に記憶された原因リンク情報５６２０を用いて、ステップＳ２１で受け付けられた各機能と対応付けられたモジュールバージョン名を特定し、さらに、特定されたモジュールバージョンを含むソフトウエアバージョンのソフトウエアバージョン名を、ソフトウエアリンク情報記憶部５３に記憶されたソフトウエアリンク情報５３０を用いて特定する（ステップＳ２２）。ここで特定されたソフトウエアバージョンは、障害（対象パッチによって除去される障害）の影響があるソフトウエアバージョンということになる。
【００８０】
続いて、リリース管理部７５が、対象パッチのパッチ名を決定する（ステップＳ２３）。具体的には、リリース管理部７５は、ステップＳ２２で特定された各ソフトウエアバージョン名を参照し、これに対象パッチの固有番号を付与した名前を、当該ソフトウエアバージョン名が付与されたソフトウエアバージョンについて作成されるべき対象パッチの名前に決定する。対象パッチの固有番号は、例えば、現在リリース完了している最新のパッチのパッチに付与された固有番号に基づいて決定することができる。ステップＳ２２で複数のソフトウエアバージョン名が特定されている場合、各ソフトウエアバージョン名に応じた複数個のパッチ名が生成されることになる。例えば、ステップＳ２で特定されたソフトウエアバージョン名が「FCK-3.3」「FCK-3.4」であれば、これに対象パッチの固有番号「01」をそれぞれ付した「Patch FCK-3.3-01」「Patch FCK-3.4-01」を対象パッチのパッチ名にそれぞれ決定する（図２３参照）。
【００８１】
続いて、モジュールバージョン名収集部７２が、モジュールリンク情報記憶部５６に記憶された実現リンク情報５６１０を用いて、ステップＳ２１で受け付けられた各機能と対応付けられたモジュールバージョン名を収集して、これらをリスト化したモジュールバージョン名リスト７２０を生成する（ステップＳ２４）。ここでリストアップされたモジュールバージョンは、対象パッチに含ませるべきモジュールバージョンとなっている。
【００８２】
続いて、試験情報取得部７３が、ステップＳ２１で受け付けられた各機能について行われた試験の試験情報５５０を試験情報記憶部５５から読み出して試験情報群７３０として取得する（ステップＳ２５）。ここで読み出された各試験情報５５０は、対象パッチにて実現される予定の各機能について行われた試験の試験情報５５０となっている。
【００８３】
続いて、リリースノート作成部７４が、ステップＳ２１で受け付けられた各機能の機能情報５４０を機能情報記憶部５４から読み出して、リリースノート７４０を作成する（ステップＳ２６）。ここで生成されるリリースノート７４０には、対象パッチにて実現される予定の各機能に関する情報が含まれることになる。
【００８４】
続いて、リリース管理部７５が、管理ファイル７５０を作成する（ステップＳ２７）。具体的には、ステップＳ２４で生成されたモジュールバージョン名リスト７２０と、ステップＳ２５で取得された試験情報群７３０と、ステップＳ２６で作成されたリリースノート７４０とを含めた管理ファイル７５０を作成し、当該管理ファイル７５０をステップＳ２３で決定された各ソフトウエアバージョン名と対応付ける。さらに、作成した管理ファイル７５０を、表示部１６（あるいは、端末装置２の表示部）に表示させる。
【００８５】
＜７．効果＞
上記の実施の形態によると、オペレータ（例えば、リリース管理者）は、アップデート用プログラムをリリースする場合に、任意のタイミングで、リリース支援装置１に管理ファイル７５０を作成させることができる。管理ファイル７５０を見ることによって、オペレータは、リリースに必要な各種の情報を簡単に取得することができる。これによって、アップデート用プログラムのリリースにおけるオペレータの作業負担が大幅に低減される。
【００８６】
すなわち、管理ファイル７５０には、リリース対象となるアップデート用プログラムに含ませるべきモジュールバージョン名のリスト（モジュールバージョン名リスト７２０）が含まれるので、オペレータは、アップデート用プログラムに含ませるべきモジュールバージョンを一目で把握することができる。
【００８７】
また、管理ファイルには、試験情報群７３０が含まれ、ここにアップデート用プログラムにおいて実現されるべき各機能の試験情報５５０が含まれる。したがって、オペレータは、アップデート用プログラムに含ませる機能について行われた試験の情報（具体的には、各機能を実現するための試験の有無およびその結果等）を簡易に取得することができる。
【００８８】
さらに、管理ファイル７５０には、リリースノート７４０が含まれ、ここにはアップデート用プログラムにおいて実現すべき各機能の機能情報５４０が含まれる。したがって、オペレータは、アップデート用プログラムにおいて実現すべき各機能に関する情報を一括して把握することができる。例えば、機能情報５４０に含まれる「ステータス」をみて、当該機能を実現するために必要なモジュールバージョンが完成しているかどうか等の情報を取得することができる。
【００８９】
また、上記の実施の形態によると、新しいバージョンのソフトウエアをリリースする場合、および、パッチをリリースする場合におけるオペレータの作業負担を低減することができる。オペレータは、障害の除去（例えば、バグ(不具合)の修正）や、比較的小規模なバージョンアップなどを行う際には、修正・追加すべき機能の実現に必要なモジュールバージョンを含むパッチをリリースすればよい。また、大規模なバージョンアップを行う際には、新しいバージョンのソフトウエアをリリースすればよい。
【００９０】
上記の実施の形態によると、特にパッチをリリースする場合に、障害（当該パッチにより除去される障害）の影響範囲（すなわち、当該障害が混入していたソフトウエアバージョンの範囲）も併せて特定されるので、パッチをリリースするべき範囲を正確かつ確実に特定することができる。したがって、パッチのリリースにおけるオペレータの作業負担が低減される。
【００９１】
＜８．変形例＞
上記の実施の形態において、リリース管理部７５がソフトウエアバージョン名を決定していたが（図１９のステップＳ１２等参照）、リリース管理部７５がソフトウエアバージョン名を決定する態様は、上記に説明したものに限らない。例えば、リリース管理部７５は、１以上のソフトウエアバージョン名の候補を表示部１６に表示し、一覧表示された候補のうちからオペレータが選択したものを、対象ソフトウエアバージョンのソフトウエアバージョン名に決定してもよい。また、リリース管理部７５は、オペレータからソフトウエアバージョン名の入力を受け付けて、当該受け付けた名前を対象ソフトウエアバージョンのソフトウエアバージョン名に決定してもよい。
【００９２】
また、上記の実施の形態においては、リリース支援装置１が管理ファイル７５０を表示させる態様までを説明している。例えば、管理ファイル７５０のリリースノート７４０から、アップデート用プログラムにおいて実現すべき全ての機能のステータスが「作成済み」となっていることが確認された場合、アップデート用プログラムのリリース処理を実行可能と判断できる。リリース処理とは、具体的には、管理ファイル７５０のモジュールバージョン名リスト７２０にリストアップされているモジュールバージョンを集めて１個のアップデート用プログラムにパッケージ化し、新たなアップデート用プログラムとしてリリースする処理である。ここで、リリース支援装置１が、リリース処理を実行する機能部をさらに備えてもよい。この変形例に係るリリース支援装置１においては、例えば、管理ファイル７５０を表示する表示画面に、アップデート用プログラムのリリース処理の実行を受け付けるアイコン等が表示される構成としてもよい。この場合、オペレータは、管理ファイル７５０をみて、リリース処理の実行が可能であると判断した場合、当該アイコンを選択操作して、リリース支援装置１にリリース処理を実行させることができる。この変形例によるとアップデート用プログラムのリリースまでの一連の作業をスムースに行うことができる。
【００９３】
また、上記の実施の形態においては、選択受付部７１にて受け付けられた各機能について行われた試験の試験情報５５０が試験情報群７３０として管理ファイル７５０に含まれる構成としたが、管理ファイル７５０には、選択受付部７１にて受け付けられた各機能と関連する他の機能について行われた試験の試験情報５５０が含まれてもよい。具体的には、試験情報取得部７３は、モジュールリンク情報５６０において、モジュールバージョン名リスト７２０にてリストアップされた全てのモジュールバージョンのいずれかと対応付けられている機能情報５４０を全て抽出し、抽出された各機能について行われた試験の試験情報５５０を試験情報群７３０に含める構成としてもよい。この場合、管理ファイル７５０には、選択受付部７１にて受け付けられた各機能と関連する他の機能について行われた試験の試験情報５５０が含まれることになる。
【００９４】
また、上記の実施の形態においては、実現リンク情報５６１０の登録は、オペレータからの操作を受け付けることにより行われていたが、実現リンク情報５６１０を登録する態様は必ずしもこれに限られない。例えば、データベース５０に、障害情報５４０ｂと障害が発生したソフトウエアバージョンとの対応関係を示す対応情報が保持されている場合、当該対応情報に基づいて、障害が発生したソフトウエアバージョンをまず特定することができる。さらに、当該ソフトウエアバージョンに含まれる１以上のモジュールバージョンを、ソフトウエアリンク情報５３０を用いて特定することができる。したがって、当該ソフトウエアバージョンに含まれる１以上のモジュールバージョンのうち、対応モジュールとして登録された各モジュールに係るモジュールバージョンを抽出することによって、実現リンク情報５６１０の登録情報を自動で（オペレータからの入力を受け付けずに）取得することができる。
【符号の説明】
【００９５】
１  リリース支援装置
５１  ソフトウエア情報記憶部
５２  モジュール情報記憶部
５３  ソフトウエアリンク情報記憶部
５４  機能情報記憶部
５５  試験情報記憶部
５６  モジュールリンク情報記憶部
７１  選択受付部
７２  モジュールバージョン名収集部
７３  試験情報取得部
７４  影響範囲特定部
７５  リリース管理部
５４０  機能情報
５４０ａ  要求情報
５４０ｂ  障害情報
５６１０  実現リンク情報
５６２０  原因リンク情報
【図１】
2012208690.tif 000003
【図２】
2012208690.tif 000004
【図３】
2012208690.tif 000005
【図４】
2012208690.tif 000006
【図５】
2012208690.tif 000007
【図６】
2012208690.tif 000008
【図７】
2012208690.tif 000009
【図８】
2012208690.tif 000010
【図９】
2012208690.tif 000011
【図１０】
2012208690.tif 000012
【図１１】
2012208690.tif 000013
【図１２】
2012208690.tif 000014
【図１３】
2012208690.tif 000015
【図１４】
2012208690.tif 000016
【図１５】
2012208690.tif 000017
【図１６】
2012208690.tif 000018
【図１７】
2012208690.tif 000019
【図１８】
2012208690.tif 000020
【図１９】
2012208690.tif 000021
【図２０】
2012208690.tif 000022
【図２１】
2012208690.tif 000023
【図２２】
2012208690.tif 000024
【図２３】
2012208690.tif 000025