JP2006331182A - ソフトウエアモジュールの不良影響解析装置、不良影響解析方法、および不良影響解プログラム - Google Patents

Abstract

【課題】ソフトウエアモジュールに生じる不良の影響範囲を効率良く調査する。
【解決手段】不良発生モジュールの不良箇所を特定する不良箇所特定部１１０と、バージョンに基づくモジュール間の親子関係の情報を格納したモジュールマスタデータベース２０１を参照し、前記不良発生モジュールを作成する基となったバージョンの親モジュールと、前記不良発生モジュールから派生して作成されたバージョンの子モジュールとを抽出する親子バージョン抽出部１１１と、前記不良箇所特定部１１０により特定した不良箇所が、前記親子バージョン抽出部１１１が抽出した親または子モジュールのバージョンに残存していることを確認する不良箇所残存チェック部１１２と、前記不良箇所の残存確認の結果を出力インターフェイスに出力する出力処理部１１３と、からシステム構成する。
【選択図】 図１

Description

本発明は、ソフトウエアモジュールの不良影響解析装置、不良影響解析方法、および不良影響解プログラムに関し、特に、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）パッケージソフトウエアに代表されるソフトウエア製品の不良影響解析を実施する技術に関する。また、更にその中でも、複数バージョンのソフトウエア、顧客要求によりカスタマイズ（修正）されたソフトウエアが存在する環境において、バージョン間の不良影響解析を効率良く実施する技術に関する。

ソフトウエア製品に不良が発生した場合に、その不良対策を実施するには、まず不良が存在しているソフトウエア内のモジュールを特定する。そこで、特定したモジュール内のプログラムステップのどこに不良が存在しているかを効率良く調査する方法が提案されている（特許文献１参照）。
特開７−１３４６６４号公報

ＥＲＰパッケージソフトウエアに代表されるソフトウエア製品では、製品リリース後のバージョンアップにより、当該ソフトウエア製品導入先の顧客では様々なバージョンのモジュールが稼動することになる。バージョンアップする、しないは顧客判断であるため、必ずしも最新バージョンのモジュールが稼動しているとは限らない。また、顧客への導入時には、顧客の要求仕様に合わせてソフトウエア製品を構成するモジュールがカスタマイズ（修正）されるケースもある。

このように、様々なバージョンのモジュール、カスタマイズされたモジュールが存在する環境では、ある特定のバージョンのモジュールに不良が発生した場合、当該バージョンのモジュールのみを対策対象とすれば良いケースはほとんどない。この場合、不良が発生したモジュールに関連する全てのバージョンのモジュール、カスタマイズされたモジュールを調査する必要がある。

こうした作業は、ソフトウエア製品の開発元が各種調査、対策を実施して行うことになるが、どの範囲のモジュールまでを調査するかは製品開発者の知識やスキルなどに依存しているのが現状である。また、カスタマイズされたモジュールについては、製品保証の対象外となって、そもそも不良の影響解析を実施しない場合もある。

しかしながら、モジュールの不良箇所が特定された後に、バージョン間やカスタマイズ有無に跨ってモジュールにおける不良箇所の有無を効率良く調査する技術は、開示されていなかった。

上記課題を解決する本発明のソフトウエアモジュールの不良影響解析装置は、ソフトウエアのモジュールに生じた不良影響を解析する装置であって、不良発生モジュールの不良箇所を特定する不良箇所特定部と、バージョンに基づくモジュール間の親子関係の情報を格納したモジュールマスタデータベースを参照し、前記不良発生モジュールを作成する基となったバージョンの親モジュールと、前記不良発生モジュールから派生して作成されたバージョンの子モジュールとを抽出する親子バージョン抽出部と、前記不良箇所特定部により特定した不良箇所が、前記親子バージョン抽出部が抽出した親または子モジュールのバージョンに残存していることを確認する不良箇所残存チェック部と、前記不良箇所の残存確認の結果を出力インターフェイスに出力する出力処理部と、を有する。

また、本発明のソフトウエアモジュールの不良影響解析装置は、各バージョンのモジュールの納入先顧客の情報を格納した顧客マスタデータベースを参照し、前記不良箇所残存チェック部により不良箇所の残存が確認されたバージョンのモジュールについてその納入先顧客の情報を抽出し、当該納入先顧客の情報に基づき該当納入先顧客への不良箇所残存の通知を実行する、不良通知部を有することとすれば好適である。

また、本発明のソフトウエアモジュールの不良影響解析装置は、前記モジュールマスタデータベースにおける各モジュールのカスタマイズ有無情報と、前記納入先顧客と前記カスタマイズの担当会社との関係情報を格納した顧客マスタデータベースとを参照し、前記カスタマイズの有無に応じて、前記不良箇所残存の通知を行う通知先を納入先顧客またはカスタマイズ担当会社のいずれかとする選択を行う、通知先選択部を有することとすれば好適である。

また、本発明のソフトウエアモジュールの不良影響解析方法は、ソフトウエアのモジュールに生じた不良影響をコンピュータにより解析する方法であって、前記コンピュータが、不良発生モジュールの不良箇所を特定し、バージョンに基づくモジュール間の親子関係の情報を格納したモジュールマスタデータベースを参照し、前記不良発生モジュールを作成する基となったバージョンの親モジュールと、前記不良発生モジュールから派生して作成されたバージョンの子モジュールとを抽出し、前記不良箇所が前記親または子モジュールのバージョンに残存していることを確認し、前記不良箇所の残存確認の結果を出力インターフェイスに出力する。

また、本発明のソフトウエアモジュールの不良影響解析プログラムは、ソフトウエアのモジュールに生じた不良影響の解析方法をコンピュータに実行させるためのプログラムであって、不良発生モジュールの不良箇所を特定するステップと、バージョンに基づくモジュール間の親子関係の情報を格納したモジュールマスタデータベースを参照し、前記不良発生モジュールを作成する基となったバージョンの親モジュールと、前記不良発生モジュールから派生して作成されたバージョンの子モジュールとを抽出するステップと、前記ステップにより特定した不良箇所が、前記親または子モジュールのバージョンに残存していることを確認するステップと、前記不良箇所の残存確認の結果を出力インターフェイスに出力するステップと、を有する。

その他、本願が開示する課題、及びその解決方法は、発明の実施の形態の欄、及び図面により明らかにされる。

本発明によれば、ソフトウエアモジュールに生じる不良の影響範囲を効率良く調査することが可能となる。

−−−システム構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は本実施形態の ソフトウエアモジュールの不良影響解析装置を含むネットワーク構成図である。このネットワーク構成例においては、本発明のソフトウエアモジュールの不良影響解析装置であり、ソフトウエアモジュールのバージョン間の不良影響解析と不良情報配信を行うソフトウエア自動配信システム１０１が、ネットワーク１４０を介して、ソフトウエア導入先となる顧客コンピュータとしてのソフトウエア導入サイト１０３、及び顧客を担当する社内部門（ソフトウエア開発元の社内との意）または社外パートナー企業が備えるソフトウエア配信中継サーバ１０２とデータ通信可能に結ばれている。

前記ソフトウエア自動配信システム１０１（以下、システム１０１）は、本発明のソフトウエアモジュールの不良影響解析方法を実現するために、モジュールマスタデータベース２０１、顧客マスタデータベース２０２、顧客導入モジュールデータベース２０３、不良情報データベース（カスタマイズ無）２０４、不良情報データベース（カスタマイズ有）２０５といった各種データベースを備えている。これらのデータベースのデータ構造例については後述する。

本発明のソフトウエアモジュールの不良影響解析装置たる前記ソフトウエア自動配信システム１０１（以下、システム１０１）は、本発明のソフトウエアモジュールの不良影響解析方法を実行する機能を実現すべく書き換え可能メモリなどのプログラムデータベース１１に格納された、ソフトウエア不良影響解析プログラム３０１、ソフトウエア不良情報配信プログラム３０２およびモジュール情報登録プログラム３０３といったプログラム１２をメモリ１３に読み出し、システム制御部５０１における演算装置たるＣＰＵ１４により実行する。

また、前記システム１０１は、コンピュータ装置が一般に備えている各種キーボードやボタン類、ディスプレイなどの入出力インターフェイス１５、ならびに、前記ソフトウエア配信中継サーバ１０２などとの間のデータ授受を担う通信手段１６などを有している。なお、前記入出力インターフェイス１５は、入力画面４０１を出力しユーザからの入力を受付可能とする。

前記システム１０１は、前記通信手段１０６により、ソフトウエア配信中継サーバ１０２らと例えばインターネットやＬＡＮ、シリアル・インターフェース通信線などのネットワーク１４０を介して接続し、データ授受を実行する。システム１０１の各種機能部と通信手段１６との間ではＩ／Ｏ部１７がデータのバッファリングや各種仲介処理を実行している。

続いて、前記システム１０１が、例えばプログラム１２に基づき構成・保持する機能部につき説明を行う。前記システム１０１は、不良発生モジュールの不良箇所を特定する不良箇所特定部１１０を備える。また、前記システム１０１は、バージョンに基づくモジュール間の親子関係の情報を格納したモジュールマスタデータベース２０１を参照し、前記不良発生モジュールを作成する基となったバージョンの親モジュールと、前記不良発生モジュールから派生して作成されたバージョンの子モジュールとを抽出する親子バージョン抽出部１１１を備える。

また、前記システム１０１は、前記不良箇所特定部１１０により特定した不良箇所が、前記親子バージョン抽出部１１１が抽出した親または子モジュールのバージョンに残存していることを確認する不良箇所残存チェック部１１２を備える。

また、前記システム１０１は、前記不良箇所の残存確認の結果を出力インターフェイスに出力する出力処理部１１３を備える。

また、前記システム１０１は、各バージョンのモジュールの納入先顧客の情報を格納した顧客マスタデータベース２０２を参照し、前記不良箇所残存チェック部１１２により不良箇所の残存が確認されたバージョンのモジュールについてその納入先顧客の情報を抽出し、当該納入先顧客の情報に基づき該当納入先顧客への不良箇所残存の通知を実行する、不良通知部１１４を備えるとすれば好適である。

また、前記システム１０１は、前記モジュールマスタデータベース２０１における各モジュールのカスタマイズ有無情報と、前記納入先顧客と前記カスタマイズの担当会社との関係情報を格納した顧客マスタデータベース２０２とを参照し、前記カスタマイズの有無に応じて、前記不良箇所残存の通知を行う通知先を納入先顧客またはカスタマイズ担当会社のいずれかとする選択を行う、通知先選択部１１５を備えるとすれば好適である。

なお、前記不良箇所特定部１１０、親子バージョン抽出部１１１、不良箇所残存チェック部１１２、および通知先選択部１１５は、図１に示すソフトウエア不良影響解析プログラム３０１が含む機能モジュールとして想定できる。また、前記出力処理部１１３および前記不良通知部１１４は、図１に示すソフトウエア不良情報配信プログラム３０２が含む機能モジュールとして想定できる。

なお、これまで示した 前記システム１０１における各機能部１１０〜１１５は、ハードウェアとして実現してもよいし、メモリやＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの適宜な記憶装置に格納したプログラムとして実現するとしてもよい。この場合、本発明のシステム１０１のＣＰＵ１４がプログラム実行に合わせて記憶装置より該当プログラム１２をメモリ１３に読み出して、これを実行することとなる。

また、前記ネットワーク１４０に関しては、インターネット、ＬＡＮの他、ＡＴＭ回線や専用回線、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、電灯線ネットワーク、無線ネットワーク、公衆回線網、携帯電話網、シリアル・インターフェース通信線など様々なネットワークを採用することも出来る。また、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）など仮想専用ネットワーク技術を用いれば、インターネットを採用した際にセキュリティ性を高めた通信が確立され好適である。なお、前記シリアル・インターフェイスは、単一の信号線を用いて１ビットずつ順次データを送るシリアル伝送で、外部機器と接続するためのインターフェースを指し、通信方式としてはＲＳ−２３２Ｃ、ＲＳ−４２２、ＩｒＤＡ、ＵＳＢ、ＩＥＥＥ１３９４、ファイバ・チャネルなどが想定できる。

−−−データベース構造−−−
次に、本実施形態のシステム１０１が利用するデータベースの構造について説明する。図２は、本実施形態における、モジュールマスタデータベース２０１のデータ構造を示す図である。前記モジュールマスタデータベース２０１は、例えば各モジュールをユニークに識別するモジュールＩＤをキーとして、モジュール名称、バージョンＮｏ．、カスタマイズされているかどうかを示すカスタマイズ有無フラグ、自身の派生元となるモジュールのモジュールＩＤを示す親モジュールＩＤといった情報を関連づけたレコードの集合体となっている。

図３は、本実施形態における、顧客マスタデータベース２０２のデータ構造を示す図である。前記マスタデータベース２０２は、例えばソフトウエアの導入先となる顧客をユニークに識別する顧客ＩＤをキーとして、顧客名称、顧客担当者氏名、顧客担当者メールアドレス、担当部署・パートナー、担当部署・パートナー担当者氏名、担当部署・パートナー担当者メールアドレスといった情報を関連づけたレコードの集合体となっている。

図４は、本実施形態における、顧客導入モジュールデータベース２０３のデータ構造を示す図である。前記顧客導入モジュールデータベース２０３は、例えば顧客ＩＤをキーとして、モジュールＩＤ、現在使用フラグといった情報を関連づけたレコードの集合体となっている。この顧客導入モジュールデータベース２０３は、モジュールマスタデータベース２０１のモジュールＩＤと顧客マスタデータベース２０２の顧客ＩＤとをキーとし、顧客に導入されたモジュールの情報を管理するためのデータベースである。なお、現在使用フラグは、導入先となる顧客で現在稼動しているモジュールを識別するためのフラグである。

図５は、本実施形態における、不良情報データベース２０４、２０５のデータ構造を示す図である。不良情報データベースとしては、モジュールがカスタマイズされている場合（カスタマイズ有）とカスタマイズされていない場合（カスタマイズ無）の２種のデータベースを想定するものとする。各不良情報データベース２０４、２０５は、例えば不良情報の送付先名称をキーとして、担当者メールアドレス、不良が発生している対象モジュール、対象モジュールのバージョンＮｏ．、不良内容、対策済みとなるモジュールの新しいバージョンＮｏ．、対策済みモジュールの所在（ＵＲＬなど）、問合せ先となる開発元担当者の氏名といった情報を関連づけたレコードの集合体となっている。

−−−メインフロー例−−−
以下、本実施形態におけるソフトウエアモジュールの不良影響解析方法の実際手順について、図に基づき説明する。なお、以下で説明するソフトウエアモジュールの不良影響解析方法に対応する各種動作は、前記ソフトウエアモジュールの不良影響解析システム１０１が、メモリ１３に読み出して実行するプログラム１２によって実現される。そして、このプログラム１２は、以下に説明される各種の動作を行うためのコードから構成されている。図６は、本実施形態のソフトウエアモジュールの不良影響解析方法におけるメインフロー例を示す図である。また、図７は、ソフトウエア不良影響解析のイメージを示す概念図であり、図８は、ソフトウエア自動配信システムの入力画面のイメージを示す概念図である。

本実施形態における、ソフトウエアモジュールのバージョン間の不良影響解析を実施する前提として、図７に示す例だと母体となるソフトウエアモジュール“Ｃｌａｓｓ１．ｊａｖａ Ｖ１.０”がバージョンアップした場合には、導入先となる顧客を担当する社内部門や社外パートナー企業が、必要に応じて最新バージョンのモジュールを顧客先にインストールするものとする。また、前記社内部門や社外パートナー企業は、必要に応じてモジュールにカスタマイズを実施して顧客先のコンピュータへのインストールをする。

こうしたインストール処理の後、社内部門、社外パートナー企業の側では、インターネット、イントラネットなどの適宜なネットワーク１４０を介して適宜な端末でもって前記システム１０１にアクセスする。その際、社内部門、社外パートナー企業が備える端末は、前記モジュール情報登録プログラム３０３を利用して、必要な情報を入力画面４０１をディスプレイ表示するなどして前記社内部門や社外パートナー企業等の担当者に提示し、その入力を受付ける。ここで前記端末が受け付けた情報はシステム１０１に送信され、例えば、モジュールマスタデータベース２０１、顧客マスタデータベース２０２、顧客導入モジュールデータベース２０３における対応モジュールについて格納あるは既存情報の更新情報とされる。

上記のような前提の下、ソフトウエアモジュール導入先となる顧客のソフトウエア導入サイト１０３において、ソフトウエアモジュールの不良が発生したとする。この場合、システム１０１における前記不良箇所特定部１１０（ソフトウエア不良影響解析プログラム３０１内）がネットワーク１４０を介して前記ソフトウエア導入サイト１０３にアクセスし、まず、不良内容、不良が発生したモジュールとモジュール内の不良箇所を調査、特定する。なお、この不良箇所特定部１１０の機能は、従来提案されてきた不良箇所特定技術の備えるものを採用すればよい。

ここでの調査、特定結果は、例えば入力画面４０１（図８参照）に示すような、不良が発生したモジュールのモジュールＩＤ、モジュール名称、バージョンＮＯ、不良内容、不良箇所に関するプログラムコードといった項目の情報を含むものであり、前記ソフトウエア不良影響解析プログラム３０１により、メモリ１３にセットされる（ステップ３０１−１）。或いは、ソフトウエア導入サイト１０３においてシステム１０１から送信された前記入力画面４０１を表示し、当該入力画面４０１を通じて前記社内部門や社外パートナー企業等の担当者による情報入力を受付けるとしてもよい。この場合、前記ソフトウエア導入サイト１０３からシステム１０１に、前記入力画面４０１での入力情報が送信され、システム１０１はこれをメモリ１３にセットすることとなる。

図７の例では、「Ｅ株式会社導入モジュール」のうち“Ｃｌａｓｓ１．ｊａｖａ Ｖ１．０”で不良が発生している。この場合に前記入力画面４０１よりの情報入力をシステム１０１が受付ける際には、モジュールＩＤ“００００１”、モジュール名称“Ｃｌａｓｓ１．ｊａｖａ”、バージョンＮｏ．“Ｖ１．０”、不良内容（図８の不良内容フィールド８０１の内容）、不良箇所に関するプログラムコード（図８の不良箇所フィールド８０２の内容）のデータを受け付けることとなる。

次に、システム１０１の前記親子バージョン抽出部１１１は、ステップ３０１−１で取得したモジュールＩＤ“００００１”で識別されるモジュールに関し、モジュールマスタデータベース２０１において、当該モジュールの親モジュールＩＤ“−”で示される親モジュールのモジュールＩＤと、当該モジュールのモジュールＩＤ“００００１”を親モジュールＩＤに持つ子モジュールのモジュールＩＤ“００００２”、“００００５”の情報を取得する（ステップ３０１−２）。なお、親モジュールＩＤ“−”とは親モジュールが存在せず、自分自身が最上位のモジュールであることを示す。

システム１０１は、上記のように取得した、親子関係にあるモジュール（これをモジュールＸと称する）に対し、影響チェック（Ｘ）を実行する（ステップ３０１−３）。なお、影響チェック（Ｘ）とは、システム１０１の不良箇所残存チェック部１１２が前記モジュールＸに対して行う、不良箇所の残存確認の処理を示す（ステップ３０１−４〜ステップ３０１−１７）。また、前記不良箇所の残存確認の結果は、システム１０１の出力処理部１１３により、適宜な出力インターフェイスに出力される。

次に、前記影響チェック（Ｘ）について説明する。ここでシステム１０１は、ステップ３０１−１でメモリ１３にセットしたプログラムコード（図８の不良箇所フィールド８０２の内容）が、モジュールＸに含まれているか、このモジュールＸのプログラムコード内を検索する（ステップ３０１−４）。この検索処理に際し、システム１０１は、オペレーティングシステムが提供する“ｄｉｆｆ”などの一般的な文字列比較コマンドを利用する。 この検索処理の結果に基づき、システム１０１は、モジュールＸに不良箇所箇所が含まれているかを判定する（ステップ３０１−５）。この判定において、モジュールＸに不良箇所が含まれている場合（ステップ３０１−５：Ｙｅｓ）、システム１０１は、モジュールマスタデータベース２０１より、モジュールＸに関するカスタマイズ有無フラグの情報を取得する（ステップ３０１−６）。このカスタマイズ有無フラグにより、システム１０１は、モジュールＸがカスタマイズされているかどうか判定する（ステップ３０１−７）。

図７の例では、モジュールＩＤ“００００２”とモジュールＩＤ“００００５”の２つのモジュールに対して、不良箇所のプログラムコード（図８の不良箇所フィールド８０２の内容）が含まれているかを検索し、２つともに不良箇所が含まれていたことを示している。従って、システム１０１は、モジュールＩＤ“００００２”のカスタマイズ有無フラグ“０”とモジュールＩＤ“００００５”のカスタマイズ有無フラグ“１”を取得し、モジュールＩＤ“００００５”のモジュールはカスタマイズされていると判定する。

前記ステップ３０１−７の判定において、モジュールＸがカスタマイズされている場合（ステップ３０１−７：Ｙｅｓ）、システム１０１は、顧客導入モジュールデータベース２０３においてモジュールＩＤ“００００５”をキーとした検索を実行し、現在使用フラグ“０”、顧客ＩＤ“ＣＵＳＴ０１”を取得する（ステップ３０１−８）。

システム１０１は、前記現在使用フラグの情報に基づき、モジュールＸが現在使用されているかを判定し（ステップ３０１−１０）、使用されていない場合（ステップ３０１−１０：Ｎｏ）は、ステップ３０１−１６に処理をスキップする。

他方、モジュールＸが現在使用されている場合（ステップ３０１−１０：Ｙｅｓ）、システム１０１は、ステップ３０１−８で取得した顧客ＩＤによる、顧客マスタデータベース２０２での検索を実行し、モジュールＸを現在使用している顧客名称、担当部署・パートナー、担当部署・パートナー担当者氏名、担当部署・パートナーメールアドレスといった情報を取得する（ステップ３０１−１２）。

さらにシステム１０１は、ステップ３０１−１でメモリ１３にセットした情報と、ステップ３０１−１２で取得した情報と、モジュールＸの名称及びバージョンＮｏ．とに基づき、不良情報データベース（カスタマイズ有）２０５において不良箇所に関するデータを追加する（ステップ３０１−１４）。この例においてシステム１０１は、モジュールＩＤ“００００５”のモジュールに対して顧客導入モジュールデータベース２０３を検索し、現在使用フラグ“０”を取得する、しかしながら、前記現在使用フラグ“０”は、前記モジュールＩＤ“００００５”のモジュールが現在使用されていないモジュールを意味するため、処理をステップ３０１−１６にスキップする。

一方、前記ステップ３０１−７で、モジュールＸがカスタマイズされていないとされた場合（ステップ３０１−７：Ｎｏ）、システム１０１は、顧客導入モジュールデータベース２０３においてモジュールＩＤ“００００２”をキーとした検索を実行し、現在使用フラグ“０”、顧客ＩＤ“ＣＵＳＴ０３”の情報を取得する（ステップ３０１−９）。

またここで、システム１０１は、上記ステップで取得した現在使用フラグの情報により、モジュールＸが現在使用されているか否かを判定する（ステップ３０１−１１）。この判定により、前記モジュールＸが使用されていない場合（ステップ３０１−１１：Ｎｏ）、システム１０１は、処理をステップ３０１−１６にスキップする。

他方、前記モジュールＸが使用されている場合（ステップ３０１−１１：Ｙｅｓ）、システム１０１は、ステップ３０１−９で取得した顧客ＩＤで顧客マスタデータベース２０２の検索を実行し、モジュールＸを現在使用している顧客名称、顧客担当者氏名、顧客担当者メールアドレスの情報を取得する（ステップ３０１−１３）。

さらにシステム１００は、ステップ３０１−１でメモリ１３にセットした情報と、ステップ３０１−１３で取得した情報と、モジュールＸの名称及びバージョンＮｏ．とに基づき、不良情報データベース（カスタマイズ無）２０４に、不良箇所に関するデータを追加する（ステップ３０１−１５）。この例でシステム１０１は、モジュールＩＤ“００００２”のモジュールに対して、顧客導入モジュールデータベース２０３を検索して現在使用フラグ“０”を取得する。しかしながら、前記現在使用フラグ“０”は、前記モジュールＩＤ“００００２”のモジュールが現在使用されていないモジュールを意味するため、処理をステップ３０１−１６にスキップする。

次にシステム１０１は、モジュールマスタデータベース２０１より、モジュールＸのモジュールＩＤ“００００２”、“００００５”を利用して、モジュールＸの親モジュールのモジュールＩＤ、子モジュールのモジュールＩＤを取得する（ステップ３０１−１６）。この処理においては、モジュールＸがステップ３０１−２で親モジュールとして取得されていた場合（モジュールマスタデータベース２０１で、不良が発生したモジュールの親モジュールＩＤとして取得されたモジュールの場合）、システム１０１は、モジュールＸの親モジュールＩＤと、まだ不良箇所の影響チェックをしていないモジュールＸの子モジュールのモジュールＩＤ（モジュールマスタデータベース２０１で、モジュールＸのモジュールＩＤを親モジュールＩＤに持つモジュールのモジュールＩＤ）を取得する。

また、モジュールＸがステップ３０１−２で子モジュールとして取得された場合（モジュールマスタデータベース２０１で、不良が発生したモジュールのモジュールＩＤを親モジュールＩＤに持つモジュールの場合）、システム１０１は、モジュールＸの子モジュールのモジュールＩＤを取得する。

図７の例では、モジュールＩＤ“００００２”のモジュールは、ステップ３０１−２で子モジュールとして取得されていたため、システム１０１は、モジュールＩＤ“００００３”とモジュールＩＤ“００００４”の２つの子モジュールを取得する。モジュールＩＤ“００００５”のモジュールは、同様にステップ３０１−２で子モジュールとして取得されていたため、システム１０１は、モジュールＩＤ“００００６”の子モジュールを取得する。

また、ステップ３０１−１６で取得したモジュール（これをモジュールＹとする）に対しては、これまでの処理と同様に、システム１０１は、取得したそれぞれのモジュールＹに対して影響チェック（Ｙ）を実行する（ステップ３０１−１３）。なお、モジュールＹとはステップ３０１−１６で取得したモジュールＩＤで識別されるモジュールを示す。また、影響チェック（Ｙ）とはモジュールＹに対する、ステップ３０１−４からステップ３０１−１７までの処理を示す。影響チェック（Ｙ）は、ステップ３０１−５において、システム１０１が、モジュールＹに不良箇所が含まれなくなるまで繰り返し実行し、モジュールＹに不良箇所が含まれている場合には、最終的にモジュールＹが最上位のモジュール（それ以上親となるモジュールが無い）、最下位のモジュール（それ以上子となるモジュールが無い）となるまで繰り返し実行する。図７の例では、モジュールＩＤ“００００３”、モジュールＩＤ“００００４”、モジュールＩＤ“００００６”の３つのモジュールに対し、システム１０１が影響チェック（Ｙ）を実行する。

モジュールＩＤ“００００３”のモジュールについて、システム１０１は、不良箇所のプログラムコードが含まれているかを検索、判定する（ステップ３０１−４、ステップ３０１−５）。本実施形態におけるモジュールＩＤ“０００３”のモジュールには、不良箇所のプログラムコードが含まれていなかったため、システム１０１は、そのまま処理を終了する。

また、モジュールＩＤ“００００４”のモジュールについても、システム１０１は、不良箇所のプログラムコードが含まれているかを検索、判定する（ステップ３０１−４、ステップ３０１−５）。本実施形態におけるモジュールＩＤ“００００４”のモジュールには、不良箇所のプログラムコードが含まれていたため、システム１０１は、ステップ３０１−６でカスタマイズ有無フラグ“１”を取得する。また、ステップ３０１−７の判定の結果、システム１０１は、モジュールＩＤ“００００４”のモジュールはカスタマイズされていると判定する。そしてシステム１０１は、このモジュールＩＤ“００００４”のモジュールについて現在使用フラグ“１”、顧客ＩＤ“ＣＵＳＴ０４”を取得する（ステップ３０１−８）。ここで取得した情報によれば、モジュールＩＤ“００００４”のモジュールは、現在使用されていると判定できるため、システム１０１は、ステップ３０１−１０、ステップ３０１−１２において、顧客名称“Ｄ株式会社”、顧客担当者氏名“ＤＤＤ”、顧客担当者メールアドレス“ＤＤＤ＠Ｄ．ｃｏ．ｊｐ”、担当部署・パートナー“Ｐ株式会社”、担当部署・パートナー担当者氏名“ＹＹＹ”、担当部署・パートナーメールアドレス“ＹＹＹ＠Ｙ．ｃｏ．ｊｐ”を取得する。またシステム１０１は、ステップ３０１−１４において、不良情報データベース（カスタマイズ有）２０５に、送付先“Ｐ株式会社 ＹＹＹ様”、送付先アドレスとなる担当部署・パートナーメールアドレス“ＹＹＹ＠Ｙ．ｃｏ．ｊｐ”、対象モジュール“Ｚ＿Ｃｌａｓｓ１．ｊａｖａ”、対象バージョンＮｏ．“Ｖ１．０”、不良内容、の各情報を追加する。

続いてシステム１０１は、モジュールＩＤ“００００４”の親モジュール、子モジュールを取得する（ステップ３０１−１６）。しかしながら、モジュールＩＤ“００００４”のモジュールは、（モジュールマスターデータベース２０１における所定モジュール間の親子関係において）最下位のモジュールであるため、以上で処理を終了する。一方、モジュールＩＤ“００００６”のモジュールの場合、システム１０１が、ステップ３０１−４で不良箇所のプログラムコードが含まれているかを検索、判定し、ステップ３０１−５にて不良箇所のプログラムコードが含まれていなかったと判定したため、そのまま処理を終了する。

システム１０１は、上記のような不良影響解析の処理をソフトウエア不良影響解析プログラム３０１の実行により行う。この処理により、不良箇所に影響を受けるモジュールが特定され、不良情報データベース２０４、２０５が作成されることとなる。また、ソフトウエア不良情報配信プログラム３０２により、入力画面４０１を介して前記社内部門や社外パートナー企業のソフトウエア配信中継サーバ１０２（或いは顧客のソフトウエア導入サイト１０３）などから、前記不良箇所への対策済みとなるモジュールのバージョンＮｏ．、対策済みモジュールの所在情報（ＵＲＬなど）、問合せ先、を取得する。ここで取得された情報は、システム１０１により不良情報データベース２０４、２０５に格納される。こうしたデータベースに対するデータ入力処理は、従来から実施されているインターネット、イントラネットを介したデータベース更新処理にあたる。

また、システム１０１のソフトウエア不良情報配信プログラム３０２は、不良情報データベース２０４、２０５の内容を、不良情報データベース２０４、２０５の送付先アドレスに基づく電子メールの発信処理により、配信する。このメール配信処理は、データベースの情報を入力としてメールを自動配信する、市販のメール配信ソフトウエアなどを利用して実現する。図７の例では、ソフトウエア不良情報配信プログラム３０２により、不良情報データベース（カスタマイズ有）２０５にセットされている、送付先“Ｐ株式会社 ＹＹＹ様”、対象モジュール“Ｚ＿Ｃｌａｓｓ１．ｊａｖａ”、対象バージョンＮｏ．“Ｖ１．０”のデータに対し、対策済みバージョンＮｏ．“Ｖ１．０１”、対策モジュール所在“ｗｗｗ．ａｂｃｄ．ｃｏ．ｊｐ”、問合せ先“Ａ氏”の情報入力を入力画面４０１から受付け、これらの情報を送付先アドレスにセットされているメールアドレスに対して自動配信することとなる（ステップ３０１−２０）。

本発明によれば、複数バージョンのモジュール間の不良影響解析、カスタマイズされたモジュール間の不良影響解析を自動化して効率良く実施することが可能となる。そのため、ソフトウエア開発元の不良対策工数の削減が実現できる。さらに、ソフトウエア不良対策の期間も短縮されるため、ソフトウエア導入先の顧客に従来よりも早く不良対策版のソフトウエアを提供することが可能となり、結果として不良ソフトウエアによる顧客業務への影響削減が実現できる。
したがって、ソフトウエアモジュールに生じる不良の影響範囲を効率良く調査することが可能となる。

以上、本発明の実施の形態について、その実施の形態に基づき具体的に説明したが、これに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

本実施形態のソフトウエアモジュールの不良影響解析装置を含むネットワーク構成を示す図である。 本実施形態におけるモジュールマスタデータベースのデータ構造を示す図である。 本実施形態における顧客マスタデータベースのデータ構造を示す図である。 本実施形態における顧客導入モジュールデータベースのデータ構造を示す図である。 本実施形態における不良情報データベースのデータ構造を示す図である。 本実施形態のソフトウエアモジュールの不良影響解析方法におけるメインフロー例を示す図である。 ソフトウエア不良影響解析のイメージを示す概念図である。 ソフトウエア自動配信システムの入力画面のイメージを示す概念図である。

符号の説明

１１ プログラムデータベース
１２ プログラム
１３ メモリ
１４ ＣＰＵ
１５ 入出力インターフェイス
１６ 通信手段
１７ Ｉ／Ｏ部
１０１ ソフトウエアモジュールの不良影響解析装置（ソフトウエア自動配信システム）
１０２ 社内部門及び社外パートナー企業のソフトウエア配信中継サーバ
１０３ ソフトウエア導入サイト
１１０ 不良箇所特定部
１１１ 親子バージョン抽出部
１１２ 不良箇所残存チェック部
１１３ 出力処理部
１１４ 不良通知部
１１５ 通知先選択部
１４０ ネットワーク
２０１ モジュールマスタデータベース
２０２ 顧客マスタデータベース
２０３ 顧客導入モジュールデータベース
２０４ 不良情報データベース（カスタマイズ無）
２０５ 不良情報データベース（カスタマイズ有）
３０１ ソフトウエア不良影響解析プログラム
３０２ ソフトウエア不良情報配信プログラム
３０３ モジュール情報登録プログラム
４０１ ソフトウエア自動配信システムの入力画面
５０１ ソフトウエア自動配信システムのシステム制御部

Claims (5)

1. ソフトウエアのモジュールに生じた不良影響を解析する装置であって、
   不良発生モジュールの不良箇所を特定する不良箇所特定部と、
   バージョンに基づくモジュール間の親子関係の情報を格納したモジュールマスタデータベースを参照し、前記不良発生モジュールを作成する基となったバージョンの親モジュールと、前記不良発生モジュールから派生して作成されたバージョンの子モジュールとを抽出する親子バージョン抽出部と、
   前記不良箇所特定部により特定した不良箇所が、前記親子バージョン抽出部が抽出した親または子モジュールのバージョンに残存していることを確認する不良箇所残存チェック部と、
   前記不良箇所の残存確認の結果を出力インターフェイスに出力する出力処理部と、
   を有する、ソフトウエアモジュールの不良影響解析装置。
2. 請求項１において、
   各バージョンのモジュールの納入先顧客の情報を格納した顧客マスタデータベースを参照し、前記不良箇所残存チェック部により不良箇所の残存が確認されたバージョンのモジュールについてその納入先顧客の情報を抽出し、当該納入先顧客の情報に基づき該当納入先顧客への不良箇所残存の通知を実行する、不良通知部を有するソフトウエアモジュールの不良影響解析装置。
3. 請求項２において、
   前記モジュールマスタデータベースにおける各モジュールのカスタマイズ有無情報と、前記納入先顧客と前記カスタマイズの担当会社との関係情報を格納した顧客マスタデータベースとを参照し、前記カスタマイズの有無に応じて、前記不良箇所残存の通知を行う通知先を納入先顧客またはカスタマイズ担当会社のいずれかとする選択を行う、通知先選択部を有するソフトウエアモジュールの不良影響解析装置。
4. ソフトウエアのモジュールに生じた不良影響をコンピュータにより解析する方法であって、前記コンピュータが、
   不良発生モジュールの不良箇所を特定し、
   バージョンに基づくモジュール間の親子関係の情報を格納したモジュールマスタデータベースを参照し、前記不良発生モジュールを作成する基となったバージョンの親モジュールと、前記不良発生モジュールから派生して作成されたバージョンの子モジュールとを抽出し、
   前記不良箇所が前記親または子モジュールのバージョンに残存していることを確認し、
   前記不良箇所の残存確認の結果を出力インターフェイスに出力する、ソフトウエアモジュールの不良影響解析方法。
5. ソフトウエアのモジュールに生じた不良影響の解析方法をコンピュータに実行させるためのプログラムであって、
   不良発生モジュールの不良箇所を特定するステップと、
   バージョンに基づくモジュール間の親子関係の情報を格納したモジュールマスタデータベースを参照し、前記不良発生モジュールを作成する基となったバージョンの親モジュールと、前記不良発生モジュールから派生して作成されたバージョンの子モジュールとを抽出するステップと、
   前記ステップにより特定した不良箇所が、前記親または子モジュールのバージョンに残存していることを確認するステップと、
   前記不良箇所の残存確認の結果を出力インターフェイスに出力するステップと、
   を有するソフトウエアモジュールの不良影響解析プログラム。