複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援するリリース支援装置であって、ソフトウエアに必要とされる機能に関する機能情報を記憶する機能情報記憶部と、ソフトウエアに必要とされる機能の前記機能情報と、当該機能を実現するために必要なモジュールバージョンの識別情報とを対応付ける実現対応情報を記憶する対応情報記憶部と、アップデート用プログラムをリリースする場合に、前記アップデート用プログラムに含ませるべき機能の選択をオペレータから受け付ける選択受付部と、前記実現対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を収集してリスト化するモジュールバージョン識別情報収集部と、を備えるリリース支援装置。請求項1に記載のリリース支援装置であって、前記アップデート用プログラムが、新しいバージョンのソフトウエアであるリリース支援装置。請求項1に記載のリリース支援装置であって、前記アップデート用プログラムが、パッチであるリリース支援装置。請求項1から3のいずれかに記載のリリース支援装置であって、前記ソフトウエアに必要とされる機能に、ソフトウエアに要求される新たな機能が含まれるリリース支援装置。請求項1から4のいずれかに記載のリリース支援装置であって、前記ソフトウエアに必要とされる機能に、ソフトウエアに発生した障害を除去するための機能が含まれるリリース支援装置。請求項5に記載のリリース支援装置であって、前記対応情報記憶部が、ソフトウエアに発生した障害を除去するための機能の前記機能情報と、当該障害の原因となったモジュールバージョンの識別情報とを対応付ける原因対応情報、をさらに記憶し、前記リリース支援装置が、前記原因対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を特定し、さらに、特定された前記モジュールバージョンを含むソフトウエアバージョンを特定する影響範囲特定部、をさらに備えるリリース支援装置。請求項1から6のいずれかに記載のリリース支援装置であって、前記ソフトウエアに必要とされる機能が当該機能を実現するためのモジュールバージョンによって適切に動作するかの試験の情報を記述した試験情報を記憶する試験情報記憶部と、前記選択受付部が受け付けた機能について行われた前記試験の前記試験情報を、前記試験情報記憶部から取得する試験情報取得部と、をさらに備えるリリース支援装置。請求項1から7のいずれかに記載のリリース支援装置であって、前記選択受付部が受け付けた機能の前記機能情報を、前記機能情報記憶部から取得する機能情報取得部、をさらに備えるリリース支援装置。CPUとメモリとを備えたコンピュータによって実行されることにより、前記コンピュータを、複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援するリリース支援装置として機能させるプログラムであって、前記CPUが前記メモリにおいて前記プログラムを実行することにより、前記コンピュータに、ソフトウエアに必要とされる機能に関する機能情報を記憶する機能情報記憶部と、ソフトウエアに必要とされる機能の前記機能情報と、当該機能を実現するために必要なモジュールバージョンの識別情報とを対応付ける実現対応情報を記憶する対応情報記憶部と、アップデート用プログラムをリリースする場合に、前記アップデート用プログラムに含ませるべき機能の選択をオペレータから受け付ける選択受付部と、前記実現対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を収集してリスト化するモジュールバージョン識別情報収集部と、を実現させるプログラム。上述したとおり、近年のソフトウエアは多数のモジュールが含まれる大規模なものとなっており、ソフトウエアに含まれる各モジュールが複雑に関連し合いながら当該ソフトウエアの各機能を実現している事が多い。さらに、バージョン系統の複雑化が進むことによって、各ソフトウエアバージョンと、当該ソフトウエアバージョンに含まれるモジュールバージョンとの対応関係も入り組んだものとなっている。したがって、多数のソフトウエアバージョンのそれぞれにおいて実現される各機能と、これを実現しているモジュールバージョンとの対応関係は非常に複雑なものとなっている。このような状況においては、新たな機能等を実現するためのアップデート用プログラムをリリースする場合に、当該機能を実現するために必要となるモジュールバージョンを特定する作業にも手間がかかる。例えば、従来、各モジュールバージョンと、当該モジュールバージョンが実現する機能との対応関係は、例えばモジュールのソースコードを用いて管理されていた。この場合、リリースの管理者等は、機能の追加を実現するためのアップデート用プログラムをリリースするにあたって、当該機能を実現するために必要なモジュールバージョンを、各モジュールバージョンのソースコードから判断して探さなければならなかった。アップデート用プログラムには、当然の事ながら、目的とする機能を実現するために必要となるモジュールバージョンが漏れなく確実に含まれている必要があるところ、リリースの管理者等が上記の判断を誤ってしまうと、新たなアップデート用プログラムにて目的とする機能が実現されないことになり、大きな問題となってしまう。したがって、上記の判断作業は、慎重に行われる必要があり、リリースの管理者等に大きな負担を強いる作業となっていた。この発明は、このような事情に鑑みてなされたものであって、アップデート用プログラムのリリースに要する作業負担を低減可能な技術を提供することを目的とする。請求項1に記載の発明は、複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援するリリース支援装置であって、ソフトウエアに必要とされる機能に関する機能情報を記憶する機能情報記憶部と、ソフトウエアに必要とされる機能の前記機能情報と、当該機能を実現するために必要なモジュールバージョンの識別情報とを対応付ける実現対応情報を記憶する対応情報記憶部と、アップデート用プログラムをリリースする場合に、前記アップデート用プログラムに含ませるべき機能の選択をオペレータから受け付ける選択受付部と、前記実現対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を収集してリスト化するモジュールバージョン識別情報収集部と、を備える。請求項2に記載の発明は、請求項1に記載のリリース支援装置であって、前記アップデート用プログラムが、新しいバージョンのソフトウエアである。請求項3に記載の発明は、請求項1に記載のリリース支援装置であって、前記アップデート用プログラムが、パッチである。請求項4に記載の発明は、請求項1から3のいずれかに記載のリリース支援装置であって、前記ソフトウエアに必要とされる機能に、ソフトウエアに要求される新たな機能が含まれる。請求項5に記載の発明は、請求項1から4のいずれかに記載のリリース支援装置であって、前記ソフトウエアに必要とされる機能に、ソフトウエアに発生した障害を除去するための機能が含まれる。請求項6に記載の発明は、請求項5に記載のリリース支援装置であって、前記対応情報記憶部が、ソフトウエアに発生した障害を除去するための機能の前記機能情報と、当該障害の原因となったモジュールバージョンの識別情報とを対応付ける原因対応情報、をさらに記憶し、前記リリース支援装置が、前記原因対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を特定し、さらに、特定された前記モジュールバージョンを含むソフトウエアバージョンを特定する影響範囲特定部、をさらに備える。請求項7に記載の発明は、請求項1から6のいずれかに記載のリリース支援装置であって、前記ソフトウエアに必要とされる機能が当該機能を実現するためのモジュールバージョンによって適切に動作するかの試験の情報を記述した試験情報を記憶する試験情報記憶部と、前記選択受付部が受け付けた機能について行われた前記試験の前記試験情報を、前記試験情報記憶部から取得する試験情報取得部と、をさらに備える。請求項8に記載の発明は、請求項1から7のいずれかに記載のリリース支援装置であって、前記選択受付部が受け付けた機能の前記機能情報を、前記機能情報記憶部から取得する機能情報取得部、をさらに備える。請求項9に記載の発明は、CPUとメモリとを備えたコンピュータによって実行されることにより、前記コンピュータを、複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援するリリース支援装置として機能させるプログラムであって、前記CPUが前記メモリにおいて前記プログラムを実行することにより、前記コンピュータに、ソフトウエアに必要とされる機能に関する機能情報を記憶する機能情報記憶部と、ソフトウエアに必要とされる機能の前記機能情報と、当該機能を実現するために必要なモジュールバージョンの識別情報とを対応付ける実現対応情報を記憶する対応情報記憶部と、アップデート用プログラムをリリースする場合に、前記アップデート用プログラムに含ませるべき機能の選択をオペレータから受け付ける選択受付部と、前記実現対応情報を用いて、前記選択受付部が受け付けた機能の前記機能情報と対応付けられた前記モジュールバージョンの識別情報を収集してリスト化するモジュールバージョン識別情報収集部と、を実現させる。請求項1、9に記載の発明によると、アップデート用プログラムをリリースする場合に、オペレータが当該アップデート用プログラムに含ませたい機能を選択してリリース支援装置に入力すると、リリース支援装置が、当該機能を実現するために必要なモジュールバージョンの識別情報をリスト化してくれるので、オペレータは、アップデート用プログラムに含ませるべきモジュールバージョンを一目で把握することができる。したがって、アップデート用プログラムのリリースにおけるオペレータの作業負担が大幅に低減される。請求項2に記載の発明によると、新しいバージョンのソフトウエアをリリースする場合におけるオペレータの作業負担を低減することができる。請求項3に記載の発明によると、パッチをリリースする場合におけるオペレータの作業負担を低減することができる。請求項4に記載の発明によると、ソフトウエアに要求される新たな機能を実現するためのアップデート用プログラムをリリースする場合において、オペレータの作業負担を低減することができる。請求項5に記載の発明によると、ソフトウエアに発生した障害を除去するための機能を実現するためのアップデート用プログラムをリリースする場合において、オペレータの作業負担を低減することができる。請求項6に記載の発明によると、ソフトウエアに発生した障害を除去するための機能を実現するためのアップデート用プログラムをリリースする場合に、当該障害の原因となったモジュールバージョンを含むソフトウエアバージョンを特定することができる。この構成によると、オペレータは、アップデート用プログラムをリリースするべき範囲を正確かつ確実に把握することができる。請求項7に記載の発明によると、アップデート用プログラムをリリースする場合に、オペレータが当該アップデート用プログラムに含ませたい機能を選択してリリース支援装置に入力すると、リリース支援装置が、当該機能について行われた試験の情報を取得する。したがって、オペレータは、アップデート用プログラムに含ませる機能について行われた試験の情報を簡易に取得することができる。請求項8に記載の発明によると、アップデート用プログラムをリリースする場合に、オペレータが当該アップデート用プログラムに含ませたい機能を選択してリリース支援装置に入力すると、リリース支援装置が、当該機能に関する機能情報を取得する。したがって、オペレータは、アップデート用プログラムに含ませる機能に関する情報を簡易に取得することができる。以下、添付の図面を参照しながら、本発明の実施形態について説明する。以下の実施形態は、本発明を具体化した一例であり、本発明の技術的範囲を限定する事例ではない。<1.開発管理システムの全体構成>本発明の実施形態に係る、ソフトウエアの開発管理システム100の構成について、図1を参照しながら説明する。図1は、開発管理システム100の概略構成を示す図である。開発管理システム100は、ソフトウエア具体的には、コンピュータに実行させるプログラムであり、装置、機器に内蔵し、その動作を制御するプログラムを含む。の開発を管理、支援するシステムであり、リリース支援装置1と、複数個の端末装置2とを、LANLocalAreaNetwork、インターネット等のネットワーク3を介して接続した構成を備えている。<リリース支援装置1>リリース支援装置1は、複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援する装置であり、コンピュータ10により構成される。図2には、リリース支援装置1を構成するコンピュータ10のハードウェア構成例が示されている。コンピュータ10は、演算処理を行うCPU11、基本プログラムを記憶するROM12、各種情報を記憶するRAM13を、バスライン20に接続した一般的なコンピュータシステムにより構成される。バスライン20にはさらに、CPU11の作業領域ワーク部分となるメモリ14、情報記憶を行う固定ディスク15、各種情報の表示を行う表示部16、マウスやキーボードで構成され、オペレータからの入力を受け付ける入力部17、コンピュータ読み取り可能な電子媒体901例えば、光ディスク、磁気ディスク、光磁気ディスク等からの情報の読み取り、および、電子媒体901への情報の書き込みを行う読取/書込装置18が接続される。さらに、バスライン20には、ネットワーク3を介して端末装置2と通信を行う通信部19が、インターフェイスI/Fを介する等して接続される。コンピュータ10が備える読取/書込装置18を介して電子媒体901から読み出されたあるいは、通信部19を介してダウンロードされたプログラム902が固定ディスク15に記憶され、さらにプログラム902がRAM13にコピーされるとともにCPU11がRAM13内のプログラム902に従ってメモリ14において演算処理を実行することによって、コンピュータ10において、リリース支援装置1としての各種の機能が実現される。<端末装置2>端末装置2は、リリース支援装置1とネットワーク3を介して接続された装置であり、リリース支援装置1に対してソフトウエアの開発管理に関する情報の登録を行うことができる。また、リリース支援装置1に対して情報の閲覧を請求するとともに、リリース支援装置1から情報の提供を受けることができる。端末装置2は、コンピュータにより構成される。端末装置2を構成するコンピュータのハードウェア構成は、上述したコンピュータ10と同様であるので、その詳細な説明を省略する。<2.ソフトウエア>リリース支援装置1は、上述したとおり、複数のモジュールを含むソフトウエアのアップデート用プログラムのリリースを支援する。リリース支援装置1について具体的に説明する前に、リリース支援装置1にて扱われるソフトウエアについて、図3を参照しながら説明する。図3は、リリース支援装置1にて扱われるソフトウエアの一例を説明するための図である。リリース支援装置1にて扱われるソフトウエアは、例えば、基板処理装置9の動作を制御するためのソフトウエア900である。基板処理装置9は、半導体ウエハなどの基板Wに薬液処理、純水処理、乾燥処理を行う装置であり、基板Wを基板処理装置9内に取り込み、また払い出しする載置台91と、基板Wを処理する複数の処理部92と、基板Wを保持して載置台91と処理部92との間を移動して基板Wを搬送する搬送機構93とを備える。基板処理装置9は、さらに、コンピュータ90を備える。ソフトウエア900がこのコンピュータ90において実行されることにより、基板処理装置9の動作を制御する制御部が構成される。図3の下段には、ソフトウエア900の構成が模式的に示されている。ソフトウエア900には、当該ソフトウエア900を識別するための情報として、ソフトウエアバージョン名が付与される。図示の例では、ソフトウエア名FCKにバージョン番号32を付したソフトウエアバージョン名FCK32が付与されている。また、ソフトウエア900は、複数個のモジュールを備える。図示されたソフトウエア900においては、基板処理装置9の全体の制御を司るモジュールモジュール名Sys、警報に関するモジュールモジュール名Arm、操作画面の表示構成に関するモジュールモジュール名Gui等を備える。さらに、各モジュールには、当該モジュールを識別するための情報としてモジュールバージョン名が付与される。図示の例では、例えば、モジュール名Sysにバージョン番号22を付したモジュールバージョン名Sys22等が付与されている。なお、ソフトウエアバージョン名FCK32や、モジュールバージョン名Sys22は、ソフトウエア、およびモジュールを識別する情報の一例であって、任意に決められるものである。<3.データベース50>リリース支援装置1の固定ディスク15には、ソフトウエアの開発管理に関する情報を登録蓄積するデータベースDB50が構築されている図2参照。データベース50の構成について、図4~図14を参照しながら説明する。図4は、データベース50の構成を模式的に示す図である。図5、図6は、データベース50に蓄積される情報の構成を説明するための図である。図7~図14は、データベース50に記憶される各情報の構成例を示す図である。データベース50は、ソフトウエア情報記憶部51と、モジュール情報記憶部52と、ソフトウエアリンク情報記憶部53とを備える。さらに、データベース50は、機能情報記憶部54と、試験情報記憶部55と、モジュールリンク情報記憶部56とを備える。リリース支援装置1の入力部17を介してオペレータから入力された情報、あるいは、ネットワーク3を介して端末装置2から受信された情報は、それぞれ所定の記憶部に蓄積されることになる。すなわち、オペレータは、リリース支援装置1の入力部17、あるいは、端末装置2の入力部を介してデータベース50に各種の情報を登録することができる。<ソフトウエア情報記憶部51>ソフトウエア情報記憶部51には、ソフトウエアバージョンに関する情報ソフトウエア情報510が記憶される。ソフトウエア情報510は、ソフトウエアの更新ごとに蓄積される。図7は、ソフトウエア情報510の構成例を模式的に示す図である。ソフトウエア情報510には、例えば、ソフトウエアバージョン名、登録日、リリース、ノート等が含まれる。ソフトウエアバージョン名は、上述の通り、ソフトウエアを識別する情報である。また、登録日は、当該ソフトウエアがデータベース50に登録された年月日である。また、リリースは当該ソフトウエアをリリースした年月日である。また、ノートは当該ソフトウエアの更新の経緯等に関する覚書である。ソフトウエア情報510には、さらに、ソフトウエア名、親となるソフトウエアバージョン名等が含まれてもよい。<モジュール情報記憶部52>モジュール情報記憶部52には、モジュールバージョンに関する情報モジュール情報520が記憶される。モジュール情報520は、ソフトウエアの構成部品であるモジュールの更新ごとに蓄積される。図8は、モジュール情報520の構成例を模式的に示す図である。モジュール情報520には、例えば、モジュールバージョン名、モジュール名、登録日、ノート等が含まれる。モジュールバージョン名は、上述の通り、モジュールを識別する情報である。また、登録日は、当該モジュールがデータベース50に登録された年月日である。また、ノートは当該モジュールの更新の経緯等に関する覚書である。モジュール情報520には、さらに、親となるモジュールバージョン名等が含まれてもよい。<ソフトウエアリンク情報記憶部53>ソフトウエアリンク情報記憶部53には、ソフトウエア情報510とモジュール情報520とをリンクする情報ソフトウエアリンク情報530が記憶される。ソフトウエアリンク情報530は、具体的には、ソフトウエアバージョンと、そのソフトウエアバージョンを構成するモジュールバージョンとをリンクさせる情報であり、例えば図9に例示するように、ソフトウエアバージョンのソフトウエアバージョン名と、そのソフトウエアバージョンを構成するモジュールバージョンのモジュールバージョン名とが対応付けられたテーブルソフトウエアリンクテーブルの形で保持される。なお、ソフトウエアにおいては、一つのソフトウエアバージョンが複数個のモジュールバージョンによって構成される一方、一つのモジュールバージョンが複数個のソフトウエアバージョンに組み込まれている場合がある。したがって、ソフトウエア情報510とモジュール情報520との関係は、いわゆる多対多となりうる。<機能情報記憶部54>機能情報記憶部54には、ソフトウエアに必要とされる機能に関する情報機能情報540が記憶される。ここで、ソフトウエアに必要とされる機能は、二種類に類型化できる。第1の類型に係る機能は、ソフトウエアに要求される新たな機能である。機能情報記憶部54には、この類の機能に関する機能情報540として、要求に関する情報要求情報540aが記憶される。要求情報540aには、例えば図10に例示するように、要求番号、要求内容、ステータス、発生日時等が含まれる。要求番号は、登録された要求を識別するための情報であり、要求の登録の際に付与される。要求内容は、要求の内容を示す情報である。ステータスは、要求に対する対応状況を示す情報である。ステータスは、例えば、要求された機能を実現するためのモジュールの作成が開始されていない場合は未対応等とされ、作成中の間は対応中、あるいは○年○月○日完成予定等とされ、要求された機能を実現するためのモジュールが完成し、ソースコードが登録された場合は作成済み等とされる。また、当該機能を実現したソフトウエアバージョンあるいは、パッチのリリースが完了すると、リリース済み等とされる。発生日時は、当該要求がデータベース50に登録された年月日である。第2の類型に係る機能は、ソフトウエアに発生した障害を除去するための機能である。機能情報記憶部54には、この類の機能に関する機能情報540として、障害に関する情報障害情報540bが記憶される。障害情報540bには、例えば図11に例示するように、障害番号、障害内容、ステータス、発生日時等が含まれる。障害番号は、登録された障害を識別するための情報であり、障害の登録の際に付与される。障害内容は、障害の内容を示す情報である。ステータスは、障害に対する対応状況を示す情報であり、要求情報540aにおけるステータスと同様である。発生日時は当該障害がデータベース50に登録された年月日である。障害情報540bとして、さらに、障害の発生が確認されたソフトウエアバージョン名が保持されてもよい。<試験情報記憶部55>試験情報記憶部55には、試験情報550が記憶される。試験情報550とは、ソフトウエアに実装するに先だって、ソフトウエアに必要とされる各機能が、当該機能を実現するための各モジュールによって適切に動作するかのテスト試験に関連する情報である。試験情報550には、例えば図12に例示するように、試験番号、試験内容、試験結果、要求障害番号、登録日等が含まれる。試験番号は、登録された試験情報550を識別するための情報であり、試験情報550の登録の際に付与される。試験内容は、行われた試験の内容方法を示す情報である。試験結果は、試験の結果を示す情報である。要求障害番号は、当該試験が対象とする機能ソフトウエアに必要とされる機能を特定するための情報であり、具体的には、例えば、当該機能に関連する機能情報540に付与された要求番号、あるいは、障害番号である。登録日は当該試験情報550がデータベース50に登録された年月日である。<モジュールリンク情報記憶部56>モジュールリンク情報記憶部56には、モジュール情報520と機能情報540とをリンクする情報モジュールリンク情報560が記憶される。モジュールリンク情報560には、ソフトウエアに必要とされる機能と、その機能を実現するモジュールバージョンとをリンクさせる情報実現リンク情報5610図5参照と、ソフトウエアに発生した障害と、その障害の原因となったモジュールバージョンとをリンクさせる情報原因リンク情報5620図6参照とが含まれる。実現リンク情報5610は、例えば図13に例示するように、ソフトウエアに必要とされる機能の要求番号、あるいは、障害番号と、当該機能を実現するモジュールバージョンのモジュールバージョン名とが対応付けられたテーブルモジュールリンクテーブルの形で保持される。なお、ソフトウエアにおいては、一つの機能は、複数個のモジュールバージョンによって実現される場合がある。一方、一つのモジュールバージョンが複数種類の機能の実現に必要とされる場合もある。したがって、機能とモジュールバージョンとの関係は、いわゆる多対多となりうる。なお、実現リンク情報5610として、ソフトウエアに要求される新たな機能と、当該機能を実現するモジュールバージョンとを対応付ける第1のテーブルと、ソフトウエアに発生した障害を除去するための機能と、当該機能を実現するモジュールバージョンとを対応付ける第2のテーブルとが別々に保持されてもよい。一方、原因リンク情報5620は、例えば図14に例示するように、ソフトウエアに発生した障害の障害番号と、当該障害の原因となったモジュールバージョンのモジュールバージョン名とが対応付けられたテーブルモジュールリンクテーブルの形で保持される。なお、ソフトウエアにおいては、一つの障害の原因が、複数個のモジュールバージョンにまたがっている場合がある。一方、一つのモジュールバージョンが複数種類の障害の原因となっている場合もある。したがって、機能とモジュールバージョンとの関係は、いわゆる多対多となりうる。<4.登録の流れ>ここで、機能情報540、試験情報550、および、モジュールリンク情報560の登録に係る処理の流れについて説明する。ソフトウエアに必要とされる機能が発生すると、オペレータ例えば、ソフトウエアの設計を担当する者が、当該機能に関する機能情報540を、入力部17あるいは、端末装置2の入力部でもよい。以下においても同様。を介して登録する。具体的には、オペレータは、ソフトウエアに新たな機能の要求が発生した場合は、要求情報540a具体的には、要求番号、要求内容、ステータス、発生日時等の各項目を登録する。また、オペレータは、ソフトウエアに障害が発生し、これを除去するための機能が必要となった場合は、障害情報540b具体的には、障害番号、障害内容、ステータス、発生日時等の各項目を登録する。オペレータから登録された各情報は、機能情報記憶部54に記憶される。機能情報540が登録されると、オペレータ例えば、ソフトウエアの設計を担当する者は、入力部17を介して、機能情報記憶部54に登録された各機能を実現するために必要なモジュール対応モジュールを登録する。図15には、対応モジュールの登録操作を支援するための画面登録画面61の構成例が示されている。ここに示されるように、登録画面61においては、ソフトウエアに含まれるモジュール名の一覧が表示される。オペレータは、機能情報記憶部54に登録された機能具体的には、機能情報540のいずれかを選択し、当該機能を実現するために必要なモジュールを選択入力する。モジュールの選択入力は、例えば、当該モジュール名のチェックボックスの位置で、入力部17のマウスを用いてクリック操作することによって行うことができる。選択入力が行われると当該モジュール名のチェックボックスにチェックマークが表示され、当該モジュールが、選択されている機能の対応モジュールとして登録される。選択されている機能を実現するために必要なモジュールが複数個存在する場合は、オペレータは、各モジュールについて上記の操作を繰り返して行うことによって、当該複数個のモジュールの全てを対応モジュールとして登録する。なお、登録画面61においては、選択した機能のステータスも入力可能としてもよい。ここで登録されたステータスの情報は、機能情報記憶部54に記憶される機能情報540に反映されることになる。機能情報記憶部54に登録された各機能とモジュールとの関係は、オペレータからの指示に応じて、表示部16に一覧表示可能とされてもよい。図16には、機能情報記憶部54に登録された各機能とモジュールとの関係を示す一覧画面62の構成例が示されている。ここに示されるように、一覧画面62においては、横軸にモジュール名の一覧が、縦軸に機能を示す情報例えば、機能情報540として登録されている要求内容、あるいは、障害内容の一覧がそれぞれ表示される。そして、あるモジュールがある機能の対応モジュールである場合は、当該モジュールの欄と当該機能の欄とが交差した領域に、マーク例えば丸印が表示される。なお、一覧画面62において、各機能のステータスに応じてその機能を示す情報の表示態様例えば、文字色等を変えてもよい。例えば、対応中の機能は赤色で表示する等してもよい。また、一覧画面62において、各対応モジュールの作成状況に応じてマークの表示態様例えば、丸印の色等を変えてもよい。例えば、ある対応モジュールにおいて機能を実現するためのモジュールバージョンの作成が完了していない場合は丸印を赤色で、完了している場合は丸印を青色で、それぞれ表示する等してもよい。続いて、オペレータ例えば、モジュールの構成管理を担当する者は、入力部17を介して、実現リンク情報5610を登録する。具体的には、オペレータは、機能情報記憶部54に登録された機能のいずれかを選択し、当該機能について登録された対応モジュールのそれぞれについて、当該機能を実現するための新たなモジュールバージョンのモジュールバージョン名を、当該機能の要求番号、あるいは、障害番号と対応付けて登録する。当該登録された情報は、実現リンク情報5610としてモジュールリンク情報記憶部56に記憶される。また、オペレータ例えば、モジュールの構成管理を担当する者は、入力部17を介して、原因リンク情報5620を登録する。具体的には、オペレータは、機能情報記憶部54に登録された機能ただし、障害を除去するための機能のいずれかを選択し、当該機能について登録された対応モジュールのそれぞれについて、当該機能において除去対象とされている障害の原因となったモジュールバージョンすなわち、障害が混入しているモジュールバージョンのモジュールバージョン名を、当該機能の障害番号と対応付けて登録する。当該登録された情報は、原因リンク情報5620としてモジュールリンク情報記憶部56に記憶される。一方、オペレータ例えば、ソフトウエアの構成管理を担当する者は、機能情報記憶部54に登録された機能を実現するための各モジュールバージョンの作成が進むと、当該モジュールバージョンによって当該機能が適切に動作するかのテスト試験を行う。試験を行った場合、オペレータは、当該試験に関する試験情報550を、入力部17を介して登録する。図17には、試験情報550の登録操作を支援するための画面登録画面63の構成例が示されている。ここに示されるように、登録画面63には、試験番号、試験内容、試験結果、登録日等の入力をそれぞれ受け付ける入力ボックスと、試験の対象となった機能の要求番号、あるいは障害番号の入力を受け付ける入力ボックスとが表示される。オペレータは、各入力ボックスに該当する情報を記入し、登録の指示を入力する。これによって、当該項目に入力された試験情報550として試験情報記憶部55に記憶される。<5.リリース支援装置1の機能構成>リリース支援装置1の機能構成について、図18を参照しながら説明する。図18は、リリース支援装置1の機能構成を示すブロック図である。リリース支援装置1は、アップデート用プログラム具体的には、新しいバージョンのソフトウエア、リリース済みのソフトウエアに修正を施すためのパッチ等のリリースを支援する機能として、選択受付部71、モジュールバージョン名収集部72、試験情報取得部73、リリースノート作成部74、リリース管理部75、および、影響範囲特定部76を備える。これらの各機能部は、コンピュータ10にプログラム902を実行させることにより実現されてもよいし、専用のハードウェアを含んで実現されてもよい。選択受付部71は、アップデート用プログラムをリリースする場合に、当該アップデート用プログラムに含ませるべき機能の選択をオペレータから受け付ける。具体的には、オペレータがアップデート用プログラムに含ませたい機能を特定するための情報例えば、要求番号、あるいは、障害番号を、入力部17あるいは、端末装置2の入力部を介して入力すると、選択受付部71は、当該入力された機能を受け付ける。モジュールバージョン名収集部72は、リリース予定のアップデート用プログラムに含ませるべきモジュールバージョンのリスト以下モジュールバージョン名リスト720というを生成する。具体的には、モジュールバージョン名収集部72は、モジュールリンク情報記憶部56に記憶された実現リンク情報5610を用いて、選択受付部71が受け付けた各機能と対応付けられたモジュールバージョン名すなわち、当該機能を実現するために必要なモジュールバージョンのモジュールバージョン名を収集してリスト化する。ここでリストアップされたモジュールバージョンは、リリース予定のアップデート用プログラムに含ませるべきモジュールバージョンとなっている。試験情報取得部73は、選択受付部71が受け付けた各機能について行われた試験の試験情報550を試験情報記憶部55から読み出して、試験情報群730として取得する。試験情報群730に含まれる各試験情報550は、リリース予定のアップデート用プログラムにて実現される予定の各機能について行われた試験の試験情報550となっている。リリースノート作成部74は、選択受付部71が受け付けた各機能の機能情報540を機能情報記憶部54から読み出して、これをまとめたファイルリリースノート740を作成する。ここで生成されるリリースノート740には、リリース予定のアップデート用プログラムにて実現される予定の各機能に関する情報具体的には、要求内容、あるいは、障害内容、発生日時等が含まれることになる。リリース管理部75は、上記の各部がそれぞれ取得した情報を取得して、これをまとめたファイル管理ファイル750を作成する。すなわち、リリース管理部75は、モジュールバージョン名収集部72から取得したモジュールバージョン名リスト720、試験情報取得部73から取得した試験情報群730、リリースノート作成部74から取得したリリースノート740をそれぞれ含んだ管理ファイル750を作成する。また、リリース管理部75は、作成した管理ファイル750を、表示部16あるいは、端末装置2の表示部に表示させる。影響範囲特定部76は、新しいパッチをリリースする場合に、当該パッチをリリースすべき範囲すなわち、障害の影響範囲を特定する。具体的には、影響範囲特定部76は、モジュールリンク情報記憶部56に記憶された原因リンク情報5620を用いて、選択受付部71が受け付けた各機能と対応付けられたモジュールバージョン名すなわち、当該機能によって除去される障害の、原因となったモジュールバージョンのモジュールバージョン名を特定する。さらに、特定されたモジュールバージョンを含むソフトウエアバージョンのソフトウエアバージョン名を、ソフトウエアリンク情報記憶部53に記憶されたソフトウエアリンク情報530を用いて特定する。ここで特定されたソフトウエアバージョンは、障害リリース予定のパッチにて除去される障害が影響するソフトウエア、すなわち、当該パッチをリリースすべきソフトウエアとなっている。<6.リリース支援装置1における処理の流れ>続いて、リリース支援装置1において実行される処理の流れについて説明する。<6-1.ソフトウエアのリリース支援>新しいソフトウエアバージョンのリリース支援に関するする処理の流れについて、図19、図20を参照しながら説明する。図19は、当該処理の流れを示す図である。図20は、当該処理を説明するための模式図である。まず、選択受付部71が、リリース予定のソフトウエアバージョン以下、対象ソフトウエアバージョンというに含ませるべき機能の選択をオペレータから受け付けるステップS11。すなわち、オペレータが対象ソフトウエアバージョンに含ませたい機能を特定するための情報例えば、要求番号、あるいは、障害番号を、入力部17あるいは、端末装置2の入力部を介して入力すると、選択受付部71は、当該入力された機能を受け付ける。ただし、オペレータは、対象ソフトウエアバージョンに含ませたい機能を複数個選択することができる。図20には、要求番号R3障害番号F1障害番号F2に係る3つの機能が対象ソフトウエアバージョンに含ませるべき機能として選択された様子が示されている。1以上の機能の選択が受け付けられると、リリース管理部75が、対象ソフトウエアバージョンのソフトウエアバージョン名を決定するステップS12。具体的には、現在リリース完了している最新のソフトウエアバージョンのソフトウエアバージョン名を参照し、これに基づいて対象ソフトウエアバージョンのソフトウエアバージョン名を決定する。例えば、現在リリース完了している最新のソフトウエアバージョンのソフトウエアバージョン名がFCK34であれば、対象ソフトウエアバージョンのソフトウエアバージョン名をFCK35に決定する。なお、ソフトウエアに複数の派生バージョンが存在している場合、ステップS11で受け付けられた機能と関連のある派生バージョン例えば、選択された機能の一部を実現している派生バージョン、選択された機能を実現するために前提となる機能を実現している派生バージョン等を一つ選択し、当該派生バージョンのバージョン系統において、現在リリース完了している最新のソフトウエアバージョンのソフトウエアバージョン名を参照して対象ソフトウエアバージョンのソフトウエアバージョン名を決定する。続いて、モジュールバージョン名収集部72が、モジュールリンク情報記憶部56に記憶された実現リンク情報5610を用いて、ステップS11で受け付けられた各機能と対応付けられたモジュールバージョン名を収集して、これらをリスト化したモジュールバージョン名リスト720を生成するステップS13。ここでリストアップされたモジュールバージョンは、対象ソフトウエアバージョンに含ませるべきモジュールバージョンとなっている。続いて、試験情報取得部73が、ステップS11で受け付けられた各機能について行われた試験の試験情報550を試験情報記憶部55から読み出して試験情報群730として取得するステップS14。ここで読み出された各試験情報550は、対象ソフトウエアバージョンにて実現される予定の各機能について行われた試験の試験情報550となっている。続いて、リリースノート作成部74が、ステップS11で受け付けられた各機能の機能情報540を機能情報記憶部54から読み出して、リリースノート740を作成するステップS15。ここで生成されるリリースノート740には、対象ソフトウエアバージョンにて実現される予定の各機能に関する情報が含まれることになる。続いて、リリース管理部75が、管理ファイル750を作成するステップS16。具体的には、ステップS13で生成されたモジュールバージョン名リスト720と、ステップS14で取得された試験情報群730と、ステップS15で作成されたリリースノート740とを含めた管理ファイル750を作成し、当該管理ファイル750をステップS12で決定されたソフトウエアバージョン名と対応付ける。さらに、作成した管理ファイル750を、表示部16あるいは、端末装置2の表示部に表示させる。<6-2.パッチのリリース支援>新しいパッチのリリース支援に関するする処理の流れについて図21~図23を参照しながら説明する。図21は、当該処理の流れを示す図である。図22、図23は、当該処理を説明するための模式図である。まず、選択受付部71が、リリース予定のパッチ以下、対象パッチというに含ませるべき機能の選択をオペレータから受け付けるステップS21。すなわち、オペレータが対象パッチに含ませたい機能を特定するための情報例えば、要求番号、あるいは、障害番号を、入力部17あるいは、端末装置2の入力部を介して入力すると、選択受付部71は、当該入力された機能を受け付ける。ただし、オペレータは、対象パッチに含ませたい機能を複数個選択することができる。図22には、障害番号F1に係る機能が対象パッチに含ませるべき機能として選択された様子が示されている。1以上の機能の選択が受け付けられると、影響範囲特定部76が、モジュールリンク情報記憶部56に記憶された原因リンク情報5620を用いて、ステップS21で受け付けられた各機能と対応付けられたモジュールバージョン名を特定し、さらに、特定されたモジュールバージョンを含むソフトウエアバージョンのソフトウエアバージョン名を、ソフトウエアリンク情報記憶部53に記憶されたソフトウエアリンク情報530を用いて特定するステップS22。ここで特定されたソフトウエアバージョンは、障害対象パッチによって除去される障害の影響があるソフトウエアバージョンということになる。続いて、リリース管理部75が、対象パッチのパッチ名を決定するステップS23。具体的には、リリース管理部75は、ステップS22で特定された各ソフトウエアバージョン名を参照し、これに対象パッチの固有番号を付与した名前を、当該ソフトウエアバージョン名が付与されたソフトウエアバージョンについて作成されるべき対象パッチの名前に決定する。対象パッチの固有番号は、例えば、現在リリース完了している最新のパッチのパッチに付与された固有番号に基づいて決定することができる。ステップS22で複数のソフトウエアバージョン名が特定されている場合、各ソフトウエアバージョン名に応じた複数個のパッチ名が生成されることになる。例えば、ステップS2で特定されたソフトウエアバージョン名がFCK33FCK34であれば、これに対象パッチの固有番号01をそれぞれ付したPatchFCK3301PatchFCK3401を対象パッチのパッチ名にそれぞれ決定する図23参照。続いて、モジュールバージョン名収集部72が、モジュールリンク情報記憶部56に記憶された実現リンク情報5610を用いて、ステップS21で受け付けられた各機能と対応付けられたモジュールバージョン名を収集して、これらをリスト化したモジュールバージョン名リスト720を生成するステップS24。ここでリストアップされたモジュールバージョンは、対象パッチに含ませるべきモジュールバージョンとなっている。続いて、試験情報取得部73が、ステップS21で受け付けられた各機能について行われた試験の試験情報550を試験情報記憶部55から読み出して試験情報群730として取得するステップS25。ここで読み出された各試験情報550は、対象パッチにて実現される予定の各機能について行われた試験の試験情報550となっている。続いて、リリースノート作成部74が、ステップS21で受け付けられた各機能の機能情報540を機能情報記憶部54から読み出して、リリースノート740を作成するステップS26。ここで生成されるリリースノート740には、対象パッチにて実現される予定の各機能に関する情報が含まれることになる。続いて、リリース管理部75が、管理ファイル750を作成するステップS27。具体的には、ステップS24で生成されたモジュールバージョン名リスト720と、ステップS25で取得された試験情報群730と、ステップS26で作成されたリリースノート740とを含めた管理ファイル750を作成し、当該管理ファイル750をステップS23で決定された各ソフトウエアバージョン名と対応付ける。さらに、作成した管理ファイル750を、表示部16あるいは、端末装置2の表示部に表示させる。<7.効果>上記の実施の形態によると、オペレータ例えば、リリース管理者は、アップデート用プログラムをリリースする場合に、任意のタイミングで、リリース支援装置1に管理ファイル750を作成させることができる。管理ファイル750を見ることによって、オペレータは、リリースに必要な各種の情報を簡単に取得することができる。これによって、アップデート用プログラムのリリースにおけるオペレータの作業負担が大幅に低減される。すなわち、管理ファイル750には、リリース対象となるアップデート用プログラムに含ませるべきモジュールバージョン名のリストモジュールバージョン名リスト720が含まれるので、オペレータは、アップデート用プログラムに含ませるべきモジュールバージョンを一目で把握することができる。また、管理ファイルには、試験情報群730が含まれ、ここにアップデート用プログラムにおいて実現されるべき各機能の試験情報550が含まれる。したがって、オペレータは、アップデート用プログラムに含ませる機能について行われた試験の情報具体的には、各機能を実現するための試験の有無およびその結果等を簡易に取得することができる。さらに、管理ファイル750には、リリースノート740が含まれ、ここにはアップデート用プログラムにおいて実現すべき各機能の機能情報540が含まれる。したがって、オペレータは、アップデート用プログラムにおいて実現すべき各機能に関する情報を一括して把握することができる。例えば、機能情報540に含まれるステータスをみて、当該機能を実現するために必要なモジュールバージョンが完成しているかどうか等の情報を取得することができる。また、上記の実施の形態によると、新しいバージョンのソフトウエアをリリースする場合、および、パッチをリリースする場合におけるオペレータの作業負担を低減することができる。オペレータは、障害の除去例えば、バグの修正や、比較的小規模なバージョンアップなどを行う際には、修正追加すべき機能の実現に必要なモジュールバージョンを含むパッチをリリースすればよい。また、大規模なバージョンアップを行う際には、新しいバージョンのソフトウエアをリリースすればよい。上記の実施の形態によると、特にパッチをリリースする場合に、障害当該パッチにより除去される障害の影響範囲すなわち、当該障害が混入していたソフトウエアバージョンの範囲も併せて特定されるので、パッチをリリースするべき範囲を正確かつ確実に特定することができる。したがって、パッチのリリースにおけるオペレータの作業負担が低減される。<8.変形例>上記の実施の形態において、リリース管理部75がソフトウエアバージョン名を決定していたが図19のステップS12等参照、リリース管理部75がソフトウエアバージョン名を決定する態様は、上記に説明したものに限らない。例えば、リリース管理部75は、1以上のソフトウエアバージョン名の候補を表示部16に表示し、一覧表示された候補のうちからオペレータが選択したものを、対象ソフトウエアバージョンのソフトウエアバージョン名に決定してもよい。また、リリース管理部75は、オペレータからソフトウエアバージョン名の入力を受け付けて、当該受け付けた名前を対象ソフトウエアバージョンのソフトウエアバージョン名に決定してもよい。また、上記の実施の形態においては、リリース支援装置1が管理ファイル750を表示させる態様までを説明している。例えば、管理ファイル750のリリースノート740から、アップデート用プログラムにおいて実現すべき全ての機能のステータスが作成済みとなっていることが確認された場合、アップデート用プログラムのリリース処理を実行可能と判断できる。リリース処理とは、具体的には、管理ファイル750のモジュールバージョン名リスト720にリストアップされているモジュールバージョンを集めて1個のアップデート用プログラムにパッケージ化し、新たなアップデート用プログラムとしてリリースする処理である。ここで、リリース支援装置1が、リリース処理を実行する機能部をさらに備えてもよい。この変形例に係るリリース支援装置1においては、例えば、管理ファイル750を表示する表示画面に、アップデート用プログラムのリリース処理の実行を受け付けるアイコン等が表示される構成としてもよい。この場合、オペレータは、管理ファイル750をみて、リリース処理の実行が可能であると判断した場合、当該アイコンを選択操作して、リリース支援装置1にリリース処理を実行させることができる。この変形例によるとアップデート用プログラムのリリースまでの一連の作業をスムースに行うことができる。また、上記の実施の形態においては、選択受付部71にて受け付けられた各機能について行われた試験の試験情報550が試験情報群730として管理ファイル750に含まれる構成としたが、管理ファイル750には、選択受付部71にて受け付けられた各機能と関連する他の機能について行われた試験の試験情報550が含まれてもよい。具体的には、試験情報取得部73は、モジュールリンク情報560において、モジュールバージョン名リスト720にてリストアップされた全てのモジュールバージョンのいずれかと対応付けられている機能情報540を全て抽出し、抽出された各機能について行われた試験の試験情報550を試験情報群730に含める構成としてもよい。この場合、管理ファイル750には、選択受付部71にて受け付けられた各機能と関連する他の機能について行われた試験の試験情報550が含まれることになる。また、上記の実施の形態においては、実現リンク情報5610の登録は、オペレータからの操作を受け付けることにより行われていたが、実現リンク情報5610を登録する態様は必ずしもこれに限られない。例えば、データベース50に、障害情報540bと障害が発生したソフトウエアバージョンとの対応関係を示す対応情報が保持されている場合、当該対応情報に基づいて、障害が発生したソフトウエアバージョンをまず特定することができる。さらに、当該ソフトウエアバージョンに含まれる1以上のモジュールバージョンを、ソフトウエアリンク情報530を用いて特定することができる。したがって、当該ソフトウエアバージョンに含まれる1以上のモジュールバージョンのうち、対応モジュールとして登録された各モジュールに係るモジュールバージョンを抽出することによって、実現リンク情報5610の登録情報を自動でオペレータからの入力を受け付けずに取得することができる。