(57)【要約】【課題】同一資産に対して複数の改修案件が並行実施される状況に関して、各環境に対する各改修案件のリリース順序の整合性を適宜なものとする。【解決手段】リリース順序チェック装置１００において、システムの改修対象たる所定資産に対し、同時期に改修を行う複数の改修案件の情報１２５を格納した記憶装置１０１と、前記情報１２５に基づき、前記複数の改修案件の間における、所定環境へのリリース時期の先後関係と、前記所定環境以外の他環境へのリリース時期の先後関係とを照合し、前記所定環境へのリリース時期の先後関係に対し、前記他環境へのリリース時期の先後関係が齟齬を生じている場合、所定通知を所定装置に出力する演算装置１０４を含む構成とする。【選択図】図２
2018101360.tif 000002
【特許請求の範囲】
【請求項１】
システムの改修対象たる所定資産に対し、同時期に改修を行う複数の改修案件の情報を格納した記憶装置と、
前記情報に基づき、前記複数の改修案件の間における、所定環境へのリリース時期の先後関係と、前記所定環境以外の他環境へのリリース時期の先後関係とを照合し、前記所定環境へのリリース時期の先後関係に対し、前記他環境へのリリース時期の先後関係が齟齬を生じている場合、所定通知を所定装置に出力する演算装置と、
ことを特徴とするリリース順序チェック装置。
【請求項２】
前記演算装置は、
前記先後関係が齟齬を生じている場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が遅い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が早い方の改修案件よりも所定期間だけ遅い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行するものである、
ことを特徴とする請求項１に記載のリリース順序チェック装置。
【請求項３】
前記演算装置は、
前記先後関係が齟齬を生じており、かつ、前記複数の改修案件の間で前記他環境へのリリース時期が同一であった場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が早い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が遅い方の改修案件よりも所定期間だけ早い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行するものである、
ことを特徴とする請求項１に記載のリリース順序チェック装置。
【請求項４】
前記演算装置は、
前記先後関係が齟齬を生じており、かつ、前記複数の改修案件の間で前記他環境へのリリース時期が同一であった場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が遅い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が早い方の改修案件よりも所定期間だけ遅い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行するものである、
ことを特徴とする請求項１に記載のリリース順序チェック装置。
【請求項５】
前記演算装置は、
前記先後関係が齟齬を生じていることに応じ、前記複数の改修案件のうちいずれかについて、前記齟齬を解消すべく前記他環境へのリリース時期に所定期間を加算または減算した後、前記照合を再実行し、前記照合の再実行の結果、前記齟齬が解消されていないことが判明した場合、前記所定期間を所定程度だけ拡大し、前記加算または前記減算を再実行する処理を行うものである、
ことを特徴とする請求項１に記載のリリース順序チェック装置。
【請求項６】
システムの改修対象たる所定資産に対し、同時期に改修を行う複数の改修案件の情報を格納した記憶装置を備えた情報処理装置が、
前記情報に基づき、前記複数の改修案件の間における、所定環境へのリリース時期の先後関係と、前記所定環境以外の他環境へのリリース時期の先後関係とを照合し、前記所定環境へのリリース時期の先後関係に対し、前記他環境へのリリース時期の先後関係が齟齬を生じている場合、所定通知を所定装置に出力する、
ことを特徴とするリリース順序チェック方法。
【請求項７】
前記情報処理装置が、
前記先後関係が齟齬を生じている場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が遅い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が早い方の改修案件よりも所定期間だけ遅い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行する、
ことを特徴とする請求項６に記載のリリース順序チェック方法。
【請求項８】
前記情報処理装置が、
前記先後関係が齟齬を生じており、かつ、前記複数の改修案件の間で前記他環境へのリリース時期が同一であった場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が早い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が遅い方の改修案件よりも所定期間だけ早い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行する、
ことを特徴とする請求項６に記載のリリース順序チェック方法。
【請求項９】
前記情報処理装置が、
前記先後関係が齟齬を生じており、かつ、前記複数の改修案件の間で前記他環境へのリリース時期が同一であった場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が遅い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が早い方の改修案件よりも所定期間だけ遅い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行する、
ことを特徴とする請求項６に記載のリリース順序チェック方法。
【請求項１０】
前記情報処理装置が、
前記先後関係が齟齬を生じていることに応じ、前記複数の改修案件のうちいずれかについて、前記齟齬を解消すべく前記他環境へのリリース時期に所定期間を加算または減算した後、前記照合を再実行し、前記照合の再実行の結果、前記齟齬が解消されていないことが判明した場合、前記所定期間を所定程度だけ拡大し、前記加算または前記減算を再実行する、
ことを特徴とする請求項６に記載のリリース順序チェック方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リリース順序チェック装置およびリリース順序チェック方法に関するものであり、具体的には、同一資産に対して複数の改修案件が並行実施される状況に関して、各環境に対する各改修案件のリリース順序の整合性を適宜なものとする技術に関する。
【背景技術】
【０００２】
複数事業者が共同で利用する業務システム等は、各事業者の要望に応じた大規模改修と、通常の稼働維持保守とが、交互に或いは並行して行われることが多い。このように、改修や保守等の案件が錯綜しうるシステムにおいては、改修案件間の整合性について配慮する必要がある。
【０００３】
こうした整合性に関連する従来技術としては、例えば、ソフトウェア開発支援装置において、ソフトウェアの設計情報を管理し、開発を支援するソフトウェア開発支援方法であって、前記ソフトウェア開発支援装置は、プロセッサ、及び前記プロセッサに接続される記憶部を備え、前記記憶部には、上流工程の設計情報と下流工程の設計情報との対応を定義する参照関係スキーマ情報と、前記設計情報間の対応関係を推定するための代替識別属性情報とが記憶され、前記方法は、前記設計情報が入力されると、前記参照関係スキーマ情報に基づいて、前記入力された設計情報に対応する参照元設計情報を特定し、前記参照元設計情報を特定できない場合には、前記代替識別属性情報に基づいて、前記参照元設計情報を推定し、前記入力された設計情報と、前記推定された参照元設計情報又は前記特定された参照元設計情報との整合性を判定し、前記整合性の判定結果に基づいて、前記入力された設計情報を登録することを特徴とするソフトウェア開発支援方法（特許文献１参照）などが提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−２８９１２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述の稼働維持保守案件にかかる期間は１，２ヶ月ほどの比較的短期であるのに対し、大規模改修案件にかかる期間は１年ほどであるケースが多く、案件間でサイクルが大きく異なりやすい。このようにサイクルが相違する条件下で、稼働維持保守案件を実施しながら、大規模改修案件を行うことになれば、対象資産の重複によるデグレードやリリースミスの発生確率が高まる恐れがある。また、政策対応や制度対応等に伴う改修案件の場合、本番環境の反映日は変更出来ないため、テスト環境へのリリースタイミングを調整し、該当案件の必要工程を確保するといった特有の条件を考慮する必要もあった。
【０００６】
そこで本発明の目的は、同一資産に対して複数の改修案件が並行実施される状況に関して、各環境に対する各改修案件のリリース順序の整合性を適宜なものとする技術を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決する本発明のリリース順序チェック装置は、システムの改修対象たる所定資産に対し、同時期に改修を行う複数の改修案件の情報を格納した記憶装置と、前記情報に基づき、前記複数の改修案件の間における、所定環境へのリリース時期の先後関係と、前記所定環境以外の他環境へのリリース時期の先後関係とを照合し、前記所定環境への
リリース時期の先後関係に対し、前記他環境へのリリース時期の先後関係が齟齬を生じている場合、所定通知を所定装置に出力する演算装置と、ことを特徴とする。
【０００８】
また、本発明のリリース順序チェック方法は、システムの改修対象たる所定資産に対し、同時期に改修を行う複数の改修案件の情報を格納した記憶装置を備えた情報処理装置が、前記情報に基づき、前記複数の改修案件の間における、所定環境へのリリース時期の先後関係と、前記所定環境以外の他環境へのリリース時期の先後関係とを照合し、前記所定環境へのリリース時期の先後関係に対し、前記他環境へのリリース時期の先後関係が齟齬を生じている場合、所定通知を所定装置に出力する、ことを特徴とする。
【発明の効果】
【０００９】
本発明によれば、同一資産に対して複数の改修案件が並行実施される状況に関して、各環境に対する各改修案件のリリース順序の整合性を適宜なものとできる。
【図面の簡単な説明】
【００１０】
【図１】本実施形態のリリース順序チェック装置を含むネットワーク構成図である。
【図２】本実施形態におけるリリース順序チェック装置のハードウェア構成例を示す図である。
【図３】本実施形態の構成管理ＤＢのデータ構成例１を示す図である。
【図４】本実施形態の構成管理ＤＢのイメージ例１を示す図である。
【図５】本実施形態のリリース順序チェック方法のフロー例１を示す図である。
【図６】本実施形態の構成管理ＤＢのイメージ例２を示す図である。
【図７】本実施形態の構成管理ＤＢのデータ構成例２を示す図である。
【図８】本実施形態の構成管理ＤＢのデータ構成例３を示す図である。
【図９】本実施形態の構成管理ＤＢのデータ構成例４を示す図である。
【図１０】本実施形態の構成管理ＤＢのデータ構成例５を示す図である。
【図１１】本実施形態のリリース順序チェック方法のフロー例２を示す図である。
【発明を実施するための形態】
【００１１】
−−−ネットワーク構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態のリリース順序チェック装置１００を含むネットワーク構成図である。図１に示すリリース順序チェック装置１００は、同一資産に対して複数の改修案件が並行実施される状況に関して、各環境に対する各改修案件のリリース順序の整合性を適宜なものとするコンピュータ装置である。
【００１２】
リリース順序チェック装置１００が、実際にチェック対象とするのは、構成管理ＤＢ１２５である。この構成管理ＤＢ１２５は、システム改修案件の対象資産であるプログラム群すなわちライブラリに関する様々な情報を格納、管理するデータベースである。
【００１３】
上述の構成管理ＤＢ１２５は、従来から利用されている一般的なデータ構成を想定するが、本実施形態では、特に、ライブラリに対して発生する改修案件それぞれのスケジュール管理用の情報も保持しているものとする。
【００１４】
なお、本実施形態では、改修の対象となるシステムとして、複数事業者が共用する業務システムを想定するものとする。また、この業務システムは所定のシステム管理センタが運用、管理している。また、上述の複数の事業者それぞれは、自身のシステムを介して業務システムを利用し、必要な業務を遂行している。また、改修案件を担当し遂行するのはベンダであるとする。従って、このベンダからすると、上述のシステム管理センタおよび事業者のそれぞれは顧客となる。
【００１５】
また、上述のベンダの担当者等は、ユーザ端末３００を操作可能である。また同様に、システム管理センタの担当者等は、ユーザ端末３０１を操作可能である。また同様に、事業者の担当者等は、ユーザ端末３０２を操作可能である。いずれのユーザ端末３００〜３０２も、ネットワーク１０を介してリリース順序チェック装置１００と通信可能に接続されるものとする。
【００１６】
また、本実施形態で想定するシステム改修の環境としては、コンパイル環境２００、結合テスト環境２０１、センタテスト環境２０２、顧客テスト環境２０３、および、本番環境２０４が含まれる。勿論、その他の環境が含まれる形態であってもよい。
【００１７】
このうちコンパイル環境２００は、改修案件を担当するベンダ等がコンパイル処理を行う環境であって、具体的にはコンパイル用のツールを備えたサーバシステムである。ベンダ等の担当者は、ユーザ端末３００を介してこのコンパイル環境２００にアクセスし、改修および単体テストが完了したプログラムのコンパイル工程を実施することになる。
【００１８】
なお、上述の構成管理ＤＢ１２５は、コンパイル環境２００に備わっている。従って、リリース順序チェック装置１００は、コンパイル環境２００に含まれるとしてもよいし、コンパイル環境２００にアクセス可能な情報処理装置であるとしてもよい。
【００１９】
上述のコンパイル工程により作成されたライブラリは、結合テスト環境２０１にリリースされる。また、結合テスト環境２０１でのライブラリのテスト結果は、該当改修を指示した顧客（具体的には、上述の事業者およびシステム管理センタの少なくともいずれか）に報告され、そのレビューに供される。顧客から承認を得たライブラリは、センタテスト環境２０２にリリースされ、システム管理センタによる動作確認等が実施される。また、この動作確認等を経たライブラリは、顧客テスト環境２０３にリリースされ、上述の事業者による動作確認等が実施される。この事業者による動作確認等を経たライブラリは、本番環境２０４にリリースされる。
【００２０】
−−−ハードウェア構成−−−
また、リリース順序チェック装置１００のハードウェア構成は以下の如くとなる。図２は、本実施形態のリリース順序チェック装置１００のハードウェア構成例を示す図である。  このリリース順序チェック装置１００は、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、ネットワーク１０と接続し、コンパイル環境２００など外部装置との通信処理を担う通信装置１０５、を備える。
【００２１】
なお、記憶装置１０１内には、本実施形態のリリース順序チェック装置として必要な機能を実装する為のプログラム１０２に加えて、コンパイル環境２００から取得し、コンパイル環境２００のものと同期をとっている構成管理ＤＢ１２５を記憶するとしてもよい。この構成管理ＤＢ１２５の詳細は後述する。
【００２２】
−−−データ構造例−−−
続いて、本実施形態のリリース順序チェック装置１００が用いるデータベースについて説明する。図３に、本実施形態における構成管理ＤＢ１２５のデータ構成例１を示す。
【００２３】
本実施形態の構成管理ＤＢ１２５は、顧客である上述の事業者（およびシステム管理セ
ンタも含めて良い）から得た、各改修案件のスケジュール管理用の情報を蓄積したデータベースである。
【００２４】
そのデータ構造は、改修案件ごとに予定される、各環境への改修後のライブラリのリリースタイミングを一意に特定するタイミング番号をキーに、リリース対象の環境にリリースを行う改修案件の名、当該改修案件で改修対象とするライブラリを一意に特定する資産名、当該資産のコンパイル日時およびサイズ、結合テスト環境２０１、センタテスト環境２０２、顧客テスト環境２０３、および本番環境２０４、それぞれへのリリース未済のステータス、結合テスト環境２０１、センタテスト環境２０２、顧客テスト環境２０３、および本番環境２０４、それぞれへのリリース予定日、といったデータから成るレコードの集合体である。
【００２５】
なお、本実施形態の構成管理ＤＢ１２５に格納される、各改修案件のスケジュール管理用の情報は、顧客が提示した設計連絡票に設定された情報である。
【００２６】
こうした構成管理ＤＢ１２５が保持する情報を、ガントチャートの形式で表すと、図４に示すイメージ例となる。図４におけるガントチャート４００にて示すように、改修案件の「Ａ案件」および「Ｂ案件」それぞれについて、所定の案件開始日からコンパイル日（結合テスト環境２０１へのリリース日でもある）までの期間に対応した「製造〜単体テスト」のバー４０１、結合テスト環境２０１へのリリース日から所定期間継続する結合テスト期間に対応した「結合テスト」のバー４０２、結合テスト完了後に所定期間継続する顧客レビュー期間に対応した「顧客レビュー」のバー４０３、センタテスト環境２０２へのリリース日から顧客テスト環境２０３へのリリース日まで継続するセンタテスト期間に対応した「センタテスト」のバー４０４、顧客テスト環境２０３へのリリース日から本番環境２０４へのリリース日まで継続する顧客テスト期間に対応した「顧客テスト」のバー４０５、が配置された構成となっている。
【００２７】
また、このガントチャート４００の下段部分には、改修対象のライブラリが、上述の各環境へのリリースに応じて、どの改修案件による改修を受けるかを示すガントチャート４１０も含んでいる。図４の例の場合、例えば、結合テスト環境に関して、「Ａ案件」の結合テスト環境２０１へのリリース日から「Ｂ案件」の結合テスト環境２０１へのリリース日までの期間において、ライブラリは「Ａ案件」による改修のみを受け、「Ｂ案件」の結合テスト環境２０１へのリリース日から以降は、「Ａ案件」と「Ｂ案件」の両方の改修を受けることを示している。
【００２８】
−−−フロー例１−−−
以下、本実施形態におけるリリース順序チェック方法の実際手順について図に基づき説明する。以下で説明するリリース順序チェック方法に対応する各種動作は、リリース順序チェック装置１００がメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
【００２９】
図５は、本実施形態のリリース順序チェック方法のフロー例１を示す図である。ここでは、同じ資産に対する改修案件である「Ａ案件」、「Ｂ案件」のスケジュールが図６に例示するガントチャート４１０の内容となっている状況を想定する。また、この場合の構成管理ＤＢ１２５における、「Ａ案件」および「Ｂ案件」の各改修案件のレコードは、図７に示すものとなっている。
【００３０】
ここで示すように、「Ａ案件」のコンパイル日時は「１６／０４／０１」、結合テスト環境２０１へのリリースは「済」、センタテスト環境２０２、顧客テスト環境２０３、お
よび本番環境２０４のそれぞれにへのリリースは「未」、結合テスト環境２０１へのリリース日は「１６／０３／３１」、センタテスト環境２０２へのリリース日は「１６／０６／３０」、顧客テスト環境２０３へのリリース日は「１６／０８／１５」、本番環境２０４へのリリース日は「１６／０９／３０」、となっている。
【００３１】
また、「Ｂ案件」のコンパイル日時は「１６／０５／０１」、結合テスト環境２０１へのリリースは「未」、センタテスト環境２０２、顧客テスト環境２０３、および本番環境２０４のそれぞれにへのリリースは「未」、結合テスト環境２０１へのリリース日は「１６／０４／３０」、センタテスト環境２０２へのリリース日は「１６／０６／３０」、顧客テスト環境２０３へのリリース日は「１６／０７／３１」、本番環境２０４へのリリース日は「１６／０８／３１」、となっている。
【００３２】
こうした状況において、リリース順序チェック装置１００は、図７のデータを含んでいる構成管理ＤＢ１２５にアクセスし、本番環境２０４へのリリースが「未」で、かつ、資産名が重複している改修案件を特定する（ｓ１００）。ここでは、資産名「００００１」に関して重複している「Ａ案件」、「Ｂ案件」が特定されることになる。なお、このステップにおいて、複数の資産に関して改修案件の重複が特定できた場合、その資産の数だけ以降のステップを繰り返すものとする（但し、当該ルーチンに関する説明は冗長なため省略する）。
【００３３】
続いて、リリース順序チェック装置１００は、特定した改修案件の数（この場合は“２”）を、変数ｉにセットする（ｓ１０１）。この「ｉ」は、構成管理ＤＢ１２５における、該当改修案件のレコードの数に対応した値、と言える。
【００３４】
次に、リリース順序チェック装置１００は、該当改修案件のうち、構成管理ＤＢ１２５での該当レコードの位置が最も下であるｉ行目の改修案件と、その１つ上の位置に該当レコードがある（ｉ−１）行目の改修案件との間で、各環境のリリース未済のステータスと、各環境へのリリース予定日とについて比較を行う（ｓ１０２）。なお、構成管理ＤＢ１２５での各改修案件のレコード位置は、コンパイル日時が早い改修案件ほど上となる。
【００３５】
この比較のうち、各環境のリリース未済のステータスに関する比較は、各環境のリリース未済のステータスが、改修案件間のコンパイル日時の順に応じたものであるか比較する処理となる。より具体的には、コンパイル日時が早い、（ｉ−１）行目の改修案件の当該ステータスが「済」、当該改修案件よりコンパイル日時が遅い、ｉ行目の改修案件のステータスが「未」、となっている場合、逆転は無い、すなわち齟齬は無いと判定する。他方、コンパイル日時が早い、（ｉ−１）行目の改修案件の当該ステータスが「未」、当該改修案件よりコンパイル日時が遅い、ｉ）行目の改修案件のステータスが「済」、となっている場合、逆転が生じている、すなわち齟齬があると判定する。
【００３６】
また、各環境へのリリース予定日に関する比較は、各環境へのリリース日が、改修案件間のコンパイル日時の順に応じたものであるか比較する処理となる。より具体的には、コンパイル日時が早い、（ｉ−１）行目の改修案件の所定環境へのリリース日が、当該改修案件よりコンパイル日時が遅い、ｉ行目の改修案件の当該環境へのリリース日より前である場合、当該環境へのリリース日に関して逆転は無い、すなわち齟齬は無いと判定する。他方、コンパイル日時が早い、（ｉ−１）行目の改修案件の所定環境へのリリース日が、当該改修案件よりコンパイル日時が遅い、ｉ）行目の改修案件の当該環境へのリリース日より遅い場合、逆転が生じている、すなわち齟齬があると判定する。
【００３７】
上述の例の場合、図７の構成管理ＤＢ１２５のデータ構成例で示すように、（ｉ−１）行目の改修案件たる「Ａ案件」の本番環境２０４へのリリース日は「１６／０９／３０」
、ｉ行目の改修案件たる「Ｂ案件」の本番環境２０４へのリリース日は「１６／０８／３１」、であるから、本番環境２０４へのリリース日に関して逆転が生じている。同様に、センタテスト環境２０２へのリリース日、および、顧客テスト環境２０３へのリリース日に関しても逆転が生じている。
【００３８】
上述の比較の結果、ステータスやリリース日に関する逆転が生じていないことが判明した場合（ｓ１０３：ｎ）、リリース順序チェック装置１００は、各改修案件のリリース順序に関して問題無い旨を示す情報を、ユーザ端末３００〜３０２の少なくともいずれかに通知し（ｓ１０４）、処理を終了する。
【００３９】
他方、上述の比較の結果、ステータスやリリース日に関する逆転が生じていることが判明した場合（ｓ１０３：ｙ）、リリース順序チェック装置１００は、本番環境２０４へのリリース日に関して逆転が生じているか判定する（ｓ１０５）。
【００４０】
上述の判定の結果、本番環境２０４へのリリース日に関して逆転が生じていないことが判明した場合（ｓ１０５：ｎ）、リリース順序チェック装置１００は、処理をｓ１１０に遷移させる。
【００４１】
当該上述の判定の結果、本番環境２０４へのリリース日に関して逆転が生じていることが判明した場合（ｓ１０５：ｙ）、リリース順序チェック装置１００は、ｓ１００で特定している改修案件のレコードを、本番環境２０４へのリリース日の昇順でソートする（ｓ１０６）。つまり、リリース順序の基準となる起点を、コンパイル日時ではなく、本番環境２０４へのリリース日とする。
【００４２】
次に、リリース順序チェック装置１００は、ｓ１０６でソートした各改修案件のレコードのうち、レコード位置が最も下であるものをｉ行目のレコード、その１つ上の位置にあるものを（ｉ−１）行目のレコードとし、あらためてｓ１０３と同様に、このｉ行目のレコードに対応した改修案件と、（ｉ−１）行目のレコードに対応した改修案件との間で、各環境のリリース未済のステータスと、各環境へのリリース予定日とについて比較を行う（ｓ１０７）。
【００４３】
上述の例の場合、図８の構成管理ＤＢ１２５のデータ構成例で示すように、（ｉ−１）行目の改修案件たる「Ｂ案件」の結合テスト環境２０１のステータスが「未」、ｉ行目の改修案件たる「Ａ案件」の結合テスト環境２０１へのステータスが「済」、であるから、結合テスト環境２０１のリリース未済のステータスに関して逆転が生じている。当然ながら、結合テスト環境２０１へのリリース日に関して逆転が生じている。また、センタテスト環境２０２へのリリース日に関しては、逆転は生じていないものの同日となっている。
【００４４】
上述の比較の結果、逆転が生じていないことが判明した場合（ｓ１０８：ｎ）、リリース順序チェック装置１００は、各環境へのリリース日の情報を構成管理ＤＢ１２５から取得し、このリリース日の情報を、各改修案件のリリース順序に関して問題無い旨と共に、ユーザ端末３００〜３０２の少なくともいずれかに通知し（ｓ１０９）、処理を終了する。
【００４５】
他方、上述の比較の結果、逆転が生じていることが判明した場合（ｓ１０８：ｙ）、リリース順序チェック装置１００は、逆転を特定した環境それぞれについて、以下のｓ１１０〜ｓ１１４を実行するものとする。
【００４６】
ｓ１１０において、リリース順序チェック装置１００は、上述の比較によって判明した逆転のうちステータスに関する逆転が生じているレコードを特定し、このレコードのうち
、ｓ１０６でのソートによってｉ行目のレコードとされたものが示すステータスを、例えば「戻す」といった値に設定し、当該環境へのリリース前の状態に該当資産を戻す必要がある旨を、ユーザ端末３００〜３０２の少なくともいずれかに通知する。上述の例の場合、図９の構成管理ＤＢ１２５の構成例で示すように、ｉ行目の改修案件たる「Ａ案件」の結合テスト環境２０１のステータスを「戻す」と設定している。
【００４７】
また、リリース順序チェック装置１００は、上述の比較によって判明した逆転が生じているレコードの間で、本番環境２０４へのリリース日の順序関係に関して齟齬を解消するよう、逆転が生じている各環境に関するリリース日の値を修正する（ｓ１１１）。
【００４８】
この修正に際し、リリース順序チェック装置１００は、例えば、上述の比較によって判明した逆転が生じているレコードのうち、ｓ１０６でのソートによって（ｉ−１）行目のレコードとされたものが示すリリース日に、所定期間のｎ日を加算し、当該加算で得たリリース日を、ｉ行目のレコードにおける当該環境へのリリース日と仮決定する。
【００４９】
上述の例の場合、図９の構成管理ＤＢ１２５の構成例で示すように、ｉ行目の改修案件たる「Ａ案件」の結合テスト環境２０１のリリース日が、当初は「１６／０３／３１」であったところ、（ｉ−１）行目のレコードの改修案件たる「Ｂ案件」の結合テスト環境２０１へのリリース日「１６／０４／３０」に７日を加算した、「１６／０５／０７」を新たなリリース日として仮決定している。
【００５０】
また、ｉ行目の改修案件たる「Ａ案件」のセンタテスト環境２０２へのリリース日と、（ｉ−１）行目の改修案件たる「Ｂ案件」のセンタテスト環境２０２へのリリース日とが、当初は共に「１６／０６／３０」で同一であったところ、「Ｂ案件」の結合テスト環境２０１へのリリース日「１６／０６／３０」を、７日減算して「１６／０６／２３」として、これを新たなリリース日として仮決定している。
【００５１】
或いは、図１０の構成管理ＤＢ１２５のデータ構成例に示すように、ｉ行目の改修案件たる「Ａ案件」のセンタテスト環境２０２へのリリース日と、（ｉ−１）行目の改修案件たる「Ｂ案件」のセンタテスト環境２０２へのリリース日とが、当初は共に「１６／０６／３０」で同一であったところ、「Ａ案件」の結合テスト環境２０１へのリリース日「１６／０６／３０」に、７日加算して「１６／０６／２３」として、これを新たなリリース日として仮決定してもよい。
【００５２】
続いて、リリース順序チェック装置１００は、ｓ１１１によって当該環境に関して仮決定した修正後のリリース日を、当該環境の次にリリースが実施される次なる環境へのリリース日と比較する（ｓ１１２）。
【００５３】
上述の比較の結果、当該環境に関して仮決定したリリース日が、次なる環境へのリリース日を超えないことが判明した場合（ｓ１１２：ｙ）、リリース順序チェック装置１００は、仮決定したリリース日を、構成管理ＤＢ１２５の該当レコードにおける当該環境のリリース日として設定し（ｓ１１３）、処理をｓ１０９に遷移させる。
【００５４】
他方、上述の比較の結果、当該環境に関して仮決定したリリース日が、次なる環境へのリリース日を超えることが判明した場合（ｓ１１２：ｎ）、リリース順序チェック装置１００は、加減算する所定期間（上述の場合、“７日”）の変更を促す通知を、ユーザ端末３００〜３０２の少なくともいずれかに通知し（ｓ１１４）、処理を終了する。
【００５５】
−−−フロー例２−−−
続いて、上述のフロー例１でリリース日の修正に際して加減算した日数を、逆転すなわ
ち齟齬が解消できる最小値になるよう自動的に改善する処理について説明する。図１１は、本実施形態のリリース順序チェック方法のフロー例２を示す図である。
【００５６】
この場合、リリース順序チェック装置１００は、上述のｓ１１１におけるリリース日の修正実行に伴い、ｓ１０３と同様に、ｉ行目の改修案件と、（ｉ−１）行目の改修案件との間で、該当環境へのリリース予定日について比較を行う（ｓ２００）。
【００５７】
なお、ｓ１１１で加算または減算した所定期間たるｎ日は、初期値として予め定めた最少日数であるとする。
【００５８】
上述の比較の結果、逆転が解消されていることが判明した場合（ｓ２０１：ｙ）、リリース順序チェック装置１００は、上述の所定期間を変更せず、処理を終了する。
【００５９】
他方、上述の比較の結果、逆転が解消されていないことが判明した場合（ｓ２０１：ｎ）、リリース順序チェック装置１００は、上述の所定期間を、例えば１日など所定程度だけ増加させ、当該増加させた所定期間の値をメモリ１０３に保持する（ｓ２０２）。
【００６０】
続いて、リリース順序チェック装置１００は、ｓ２０２でメモリ１０３に保持した所定期間の値で、ｓ１１１のリリース日の修正、すなわちリリース日の加算または減算を再実行し（ｓ２０３）、処理をｓ２００に戻す。
【００６１】
以上の処理を繰り返すことで、リリース日の修正に際して過度な日数を加算ないし減算する事態を的確に回避し、リリース日の逆転解消を必要最小限の日数修正で行うことが可能となる。
【００６２】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【００６３】
こうした本実施形態によれば、稼働維持保守案件における頻繁な（1回/月ペースで）プログラムの改修と、大規模改修案件におけるプログラムの改修とが、同一の資産（ライブラリ）に対して輻輳する状況に関して、修正順序とリリース順序の妥当性をチェック可能である。また、こうしたチェックでエラーを検知した場合、推奨するリリース予定日をユーザに提示できる。
【００６４】
こうした本実施形態のリリース順序チェック技術を利用するシステム開発者等は、ライブラリリリースの順序不正やテスト漏れを防ぐことが可能になり、不具合なく確実にライブラリをリリース出来ることとなる。
【００６５】
すなわち、同一資産に対して複数の改修案件が並行実施される状況に関して、各環境に対する各改修案件のリリース順序の整合性を適宜なものと出来る。
【００６６】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のリリース順序チェック装置において、前記演算装置は、前記先後関係が齟齬を生じている場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が遅い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が早い方の改修案件よりも所定期間だけ遅い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行するものである、としてもよい。
【００６７】
これによれば、本番環境へのリリース時期の先後関係に即して、各改修案件の間での、結合テスト環境やセンタテスト環境（第１の顧客テスト環境）、協会テスト環境（第２の
テスト環境）といった他環境へのリリース時期の先後関係についても効率良く修正し、その齟齬を解消出来る。ひいては、同一資産に対して複数の改修案件が並行実施される状況に関して、各環境に対する各改修案件のリリース順序の整合性を効率的に適宜なものと出来る。
【００６８】
また、本実施形態のリリース順序チェック装置において、前記演算装置は、前記先後関係が齟齬を生じており、かつ、前記複数の改修案件の間で前記他環境へのリリース時期が同一であった場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が早い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が遅い方の改修案件よりも所定期間だけ早い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行するものである、としてもよい。
【００６９】
これによれば、本番環境へのリリース時期の先後関係に即して、各改修案件の間での、結合テスト環境やセンタテスト環境、協会テスト環境といった他環境へのリリース時期が同一となっていても、これを適切な先後関係に効率良く修正し、その齟齬を解消出来る。ひいては、同一資産に対して複数の改修案件が並行実施される状況に関して、各環境に対する各改修案件のリリース順序の整合性を効率的に適宜なものと出来る。
【００７０】
また、本実施形態のリリース順序チェック装置において、前記演算装置は、前記先後関係が齟齬を生じており、かつ、前記複数の改修案件の間で前記他環境へのリリース時期が同一であった場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が遅い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が早い方の改修案件よりも所定期間だけ遅い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行するものである、としてもよい。
【００７１】
これによれば、本番環境へのリリース時期の先後関係に即して、各改修案件の間での、結合テスト環境やセンタテスト環境、協会テスト環境といった他環境へのリリース時期が同一となっていても、これを適切な先後関係に効率良く修正し、その齟齬を解消出来る。ひいては、同一資産に対して複数の改修案件が並行実施される状況に関して、各環境に対する各改修案件のリリース順序の整合性を効率的に適宜なものと出来る。
【００７２】
また、本実施形態のリリース順序チェック装置において、前記演算装置は、前記先後関係が齟齬を生じていることに応じ、前記複数の改修案件のうちいずれかについて、前記齟齬を解消すべく前記他環境へのリリース時期に所定期間を加算または減算した後、前記照合を再実行し、前記照合の再実行の結果、前記齟齬が解消されていないことが判明した場合、前記所定期間を所定程度だけ拡大し、前記加算または前記減算を再実行する処理を行うものである、としてもよい。
【００７３】
これによれば、本番環境へのリリース時期の先後関係に即して、各改修案件の間での、結合テスト環境やセンタテスト環境、協会テスト環境といった他環境へのリリース時期の先後関係について、無駄のない期間で精度良く修正し、その齟齬を解消出来る。ひいては、同一資産に対して複数の改修案件が並行実施される状況に関して、各環境に対する各改修案件のリリース順序の整合性を精度良く適宜なものと出来る。
【００７４】
また、本実施形態のリリース順序チェック方法において、前記情報処理装置が、前記先後関係が齟齬を生じている場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が遅い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が早い方の改修案件よりも所定期間だけ遅い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行する、としてもよい。
【００７５】
また、本実施形態のリリース順序チェック方法において、前記情報処理装置が、前記先後関係が齟齬を生じており、かつ、前記複数の改修案件の間で前記他環境へのリリース時期が同一であった場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が早い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が遅い方の改修案件よりも所定期間だけ早い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行する、としてもよい。
【００７６】
また、本実施形態のリリース順序チェック方法において、前記情報処理装置が、前記先後関係が齟齬を生じており、かつ、前記複数の改修案件の間で前記他環境へのリリース時期が同一であった場合に、前記複数の改修案件のうち前記所定環境へのリリース時期が遅い方の改修案件について、前記他環境へのリリース時期を、前記所定環境へのリリース時期が早い方の改修案件よりも所定期間だけ遅い時期に変更し、前記変更の内容を示す情報を所定装置に出力する処理を更に実行する、としてもよい。
【００７７】
また、本実施形態のリリース順序チェック方法において、前記情報処理装置が、前記先後関係が齟齬を生じていることに応じ、前記複数の改修案件のうちいずれかについて、前記齟齬を解消すべく前記他環境へのリリース時期に所定期間を加算または減算した後、前記照合を再実行し、前記照合の再実行の結果、前記齟齬が解消されていないことが判明した場合、前記所定期間を所定程度だけ拡大し、前記加算または前記減算を再実行する、としてもよい。
【符号の説明】
【００７８】
１０    ネットワーク
１００  リリース順序チェック装置
１０１  記憶装置
１０２  プログラム
１０３  メモリ
１０４  演算装置
１０５  通信装置
１２５  構成管理ＤＢ
２００  コンパイル環境
２０１  結合テスト環境
２０２  センタテスト環境
２０３  顧客テスト環境
２０４  本番環境
３００〜３０２  ユーザ端末
４００、４１０  ガントチャート
【図１】
2018101360.tif 000003
【図２】
2018101360.tif 000004
【図３】
2018101360.tif 000005
【図４】
2018101360.tif 000006
【図５】
2018101360.tif 000007
【図６】
2018101360.tif 000008
【図７】
2018101360.tif 000009
【図８】
2018101360.tif 000010
【図９】
2018101360.tif 000011
【図１０】
2018101360.tif 000012
【図１１】
2018101360.tif 000013