JP2013164673A - ソフトウェア管理システムおよびその管理方法 - Google Patents

Abstract

【課題】ソフトウェア構成管理システムの変更に伴う対応を最小限に抑え、長期的な運用に耐えうるソフトウェア管理システムを提供する。
【解決手段】ソフトウェア開発に係るファイルの変更履歴を含むファイル管理を行うためのサーバシステムであるソフトウェア管理システム１において、ファイル管理を行うソフトウェア構成管理システム２１と、ソフトウェア管理システム１において規定された要求を、ソフトウェア構成管理システム２１に対して受け付ける要求対応機能６２〜６６と、要求対応機能６２〜６６が受け付ける要求と、ソフトウェア構成管理システム２１が専用に受け付ける要求とを相互に変換し、要求対応機能６２〜６６とソフトウェア構成管理システム２１とのインタフェース機能を有するインタフェース部６７とを備えた。
【選択図】 図２

Description

本発明は、ソフトウェア管理システムおよびその管理方法に関する。

近年、高度なソフトウェア構成管理機能を有するオープンソースソフトウェアやフリーソフトウェア、商用のソフトウェアが多数存在している。このため、ソフトウェア構成管理システム（ＳＣＭ（Software Configuration Management）システム）を自社開発することは少なく、既存のソフトウェアを採用するのが一般的である。例えば、代表的なＳＣＭシステムとしては、ＣＶＳ、Ｓｕｂｖｅｒｓｉｏｎ、Ｇｉｔ、Ｍｅｒｃｕｒｉａｌ、Ｂａｚａａｒ（登録商標）などがある。

また、引用文献１においては、ＣＶＳやＳｕｂｖｅｒｓｉｏｎを使用したソフトウェア構成管理システムが開示されている。

特開２０１０−３３３７３号公報

ソフトウェア管理システム（サーバ）は、ＳＣＭシステムを構成するソフトウェア（ＳＣＭソフトウェア）のセキュリティ問題の解消や、最新バージョンの提供にともなって、ＳＣＭソフトウェアのバージョンアップをインターネット経由で行うソフトウェアアップデート機能を有する。

特に、セキュリティ問題対応のためのアップデートは、最優先で行う必要がある。しかし、ＳＣＭソフトウェアの機能、性能などに対して、アップデート前後で確実に互換性があることや、ソフトウェアに新たな問題が含まれていないことの保証は、現実問題として困難である。

ソフトウェアアップデート機能を使用せずに、人間系によるＳＣＭソフトウェアのバージョンアップを行った場合にも、同様に、互換性や新たな問題が含まれていないことの保証を得ることは困難である。

また、例えば、電力設備や公共設備などのインフラ向けに開発されているソフトウェアは、１０〜２０年にも及ぶ管理・メンテナンスが必要となる場合も少なくない。ＳＣＭソフトウェアの使用が長期にわたると、ＳＣＭソフトウェアに仕様変更や製品提供終了が発生する可能性がある。自社開発でないＳＣＭソフトウェアを採用している場合には、仕様変更や製品提供終了に関する問題をコントロールすることはできない。これにより、ソフトウェア管理システムの品質低下が発生し、ＳＣＭシステムが管理するソース成果物の信頼性の低下が発生する恐れがある。
さらに、ＳＣＭシステムの仕様変更や新たなＳＣＭへの入れ替えに伴い、ＳＣＭシステムに付随するソフトウェア管理システム内の各種機能との間のインタフェース部分の改造および動作検証作業が発生する可能性がある。これは、長期間にわたるソフトウェア管理システムの停止や、ソフトウェア管理システムの大規模な、改造・検証費用を発生させる。

本発明はこのような事情を考慮してなされたもので、ソフトウェア構成管理システムの変更に伴う対応を最小限に抑え、長期的な運用に耐えうるソフトウェア管理システムおよびその管理方法を提供することを目的とする。

本発明に係るソフトウェア管理システムは、上述した課題を解決するために、ソフトウェア開発に係るファイルの変更履歴を含むファイル管理を行うためのサーバシステムであるソフトウェア管理システムにおいて、前記ファイル管理を行うソフトウェア構成管理システムと、前記ソフトウェア管理システムにおいて規定された要求を受け付ける要求対応部と、前記要求対応部が受け付けた前記要求を、前記ソフトウェア構成管理システムが専用に受け付ける要求に変換し、前記要求対応部と前記ソフトウェア構成管理システムとのインタフェース機能を有するインタフェース部とを備えたことを特徴とする。

本発明に係るソフトウェア管理システムおよびその管理方法においては、ソフトウェア構成管理システムの変更に伴う対応を最小限に抑え、長期的な運用に耐えることができる。

本発明の第１実施形態に係るソフトウェア管理システムのブロック構成図。 第１実施形態におけるソース成果物操作クライアントおよびＳＣＭ Ｉ／Ｆ機能の詳細な機能ブロック構成図。 ＳＣＭ健全性確認対応機能により実行されるＳＣＭ健全性確認処理を説明するフローチャート。 第１実施形態におけるソフトウェア管理システムのＳＭＣ Ｉ／Ｆ機能で実行される、ＳＣＭプラグインＩ／Ｆが各種要求を受け取った場合に実行される要求実施処理を説明するフローチャート。 本発明の第２実施形態に係るソフトウェア管理システムのブロック構成図。 第２実施形態におけるＳＣＭ Ｉ／Ｆ機能の詳細な機能ブロック構成図。 第２実施形態におけるＳＣＭ健全性確認対応機能により実行されるＳＣＭ健全性確認処理を説明するフローチャート。 図７のＳＣＭ健全性確認処理の一部の処理を説明するフローチャート。 第２実施形態におけるソフトウェア管理システムのＳＣＭプラグインＩ／Ｆが各種要求を受け取った場合に実行される要求実施処理を説明するフローチャート。 図７、図８のＳＣＭ健全性確認処理のフラグリセットステップＳ５０に続くＳＣＭ健全性確認処理を説明するフローチャート。 第３実施形態におけるＳＣＭ Ｉ／Ｆ機能の詳細な機能ブロック構成図。 第３実施形態におけるソフトウェア管理システムのデータ自動復元機能により実行されるデータ自動復元処理を説明するフローチャート。 第３実施形態におけるソフトウェア管理システムのＳＣＭプラグインＩ／Ｆが各種要求を受け取った場合に実行される要求実施処理を説明するフローチャート。

本発明に係るソフトウェア管理システムおよびその管理方法の第１〜第３実施形態を添付図面に基づいて説明する。

［第１実施形態］
図１は、本発明の第１実施形態に係るソフトウェア管理システム１のブロック構成図である。

ソフトウェア管理システム１は、開発者１１により開発されたファイルの変更履歴を含むファイル管理を行うためのサーバシステムである。ソフトウェア管理システム１は、ソフトウェア開発者１１のソフトウェア開発用パーソナルコンピュータ（ＰＣ）２、およびソフトウェア利用者３１のＷｅｂブラウザ３と通信する。

ソフトウェア開発用ＰＣ２は、ソフトウェアの開発者１１により操作される。ソフトウェア開発用ＰＣ２は、ソース成果物操作クライアント１２およびソース成果物１３を有する。ソース成果物１３は、ソフトウェア開発用ＰＣ２にて開発されたソースコードファイル、ソースコードに付随するコンパイル／ビルド情報ファイル、最終的な成果物である実行ファイル、途中成果物であるオブジェクトファイルを含むファイルである。

ソース成果物操作クライアント１２は、ソフトウェア管理システム１のＳＣＭインタフェース（Ｉ／Ｆ）機能２２専用のクライアントである。ソース成果物操作クライアント１２は、ソフトウェア管理システム１と通信する際、ＳＣＭ Ｉ／Ｆ機能２２を介して通信する。

ソース成果物操作クライアント１２は、ソフトウェア管理システム１（ＳＣＭ Ｉ／Ｆ機能２２）に対してソース成果物１３をソース成果物一時コピー２３へ送信し、ソース成果物一時コピー２３をＳＣＭシステム２１へ登録／管理することをＳＣＭ Ｉ／Ｆ機能２２へ要求する。また、ソース成果物操作クライアント１２は、ソフトウェア管理システム１に対してソース成果物一時コピー２３の取り出しを要求し、ＳＣＭシステム２１に管理されているソース成果物を取得する。

ソース成果物操作クライアント１２は、ソフトウェア管理システム１に対して変更点確認などのため管理情報の取得を要求する。

ソフトウェア管理システム１は、ソフトウェア構成管理システム（ＳＣＭシステム）２１、ＳＣＭインタフェース機能（ＳＣＭ Ｉ／Ｆ機能）２２、ソース成果物一時コピー２３、変更点管理機能２５、リリース管理機能２６、その他の社内特有機能２７、Ｗｅｂインタフェース機能２８、およびソフトウェアアップデート機能２９を備える。

ＳＣＭシステム２１は、ソフトウェアの構成管理機能を有し、コンピュータ上で作成、編集されるファイルの変更履歴を管理するためのソフトウェアである。例えば、オープンソースソフトウェアやフリーソフトウェア、商用のソフトウェアを採用することができる（例えば、ＣＶＳ、Ｓｕｂｖｅｒｓｉｏｎ、Ｇｉｔ、Ｍｅｒｃｕｒｉａｌ、Ｂａｚａａｒ）。

ＳＣＭ Ｉ／Ｆ機能２２は、ソフトウェア開発用ＰＣ２のソース成果物操作クライアント１２や、ソフトウェア管理システム１の変更点管理機能２５など各種機能と、ＳＣＭシステム２１とのインタフェースである。具体的には、ＳＣＭ Ｉ／Ｆ機能２２は、開発者１１が作成したソース成果物１３がＳＣＭシステム２１へ登録、変更される場合に、ソース成果物操作クライアント１２より要求を受け付け、ＳＣＭシステム２１に対して送信する。ＳＣＭ Ｉ／Ｆ機能２２は、変更点管理機能２５などがＳＣＭシステム２１により管理される情報を利用する要求を行う際、その要求を受け付け、ＳＣＭシステム２１に対して送信する。

すなわち、ソフトウェア管理システム１は、ＳＣＭシステム２１に対する要求はＳＣＭ Ｉ／Ｆ機能２２から行われ、ＳＣＭ Ｉ／Ｆ機能２２以外の機能からは直接要求が行われない。

ソース成果物一時コピー２３は、ソフトウェア開発用ＰＣ２より受信したソース成果物１３の一時コピーである。

変更点管理機能２５、リリース管理機能２６、およびその他の社内特有機能２７は、ＳＣＭ Ｉ／Ｆ機能２２を介してＳＣＭシステム２１へ各種要求を行い、必要な情報を取得する。これらの機能２５〜２７は、Ｗｅｂインタフェース機能２８を経由して、Ｗｅｂブラウザ３を介して必要な情報を利用者３１に提供する。

変更点管理機能２５は、ソース成果物の変更点を変更管理情報として取得する。リリース管理機能２６は、ソース成果物に含まれる実行ファイルなどのリリース対象物を取得する。その他の社内特有機能２７は、変更管理情報やリリース対象物以外の本システムを運用する組織特有の機能を実現する上で必要な各種情報を取得する。

変更点管理機能２５、リリース管理機能２６、その他の社内特有機能２７は、公知の技術を適用できるため、ここでは詳細な説明を省略する。

ソフトウェアアップデート機能２９は、ＳＣＭシステム２１を構成するソフトウェア（ＳＣＭソフトウェア）のセキュリティ問題の解消や、最新バージョンの提供に伴い、インターネット４０経由で、ＳＣＭソフトウェアのバージョンアップを行う機能である。ソフトウェアアップデート機能２９は、オペレーションシステム（ＯＳ）や、ＳＣＭソフトウェア自身により提供される。

なお、利用者３１へ提供されるユーザーインタフェースは、Ｗｅｂインタフェース機能２８およびＷｅｂブラウザ３に限らず、専用のインターフェースソフトウェアと専用のクライアントソフトウェアであってもよい。ソース成果物操作クライアント１２とＳＣＭ Ｉ／Ｆ機能２２との間のインタフェースは、Ｗｅｂブラウザをクライアントとしてもよい。

次に、ソース成果物操作クライアント１２およびＳＣＭ Ｉ／Ｆ機能２２の詳細な機能について説明する。

図２は、第１実施形態におけるソース成果物操作クライアント１２およびＳＣＭ Ｉ／Ｆ機能２２の詳細な機能ブロック構成図である。

ソース成果物操作クライアント１２は、ソース成果物送受信機能５１、成果物一覧情報整合機能５２、変更点確認機能５３、コミット機能５４、チェックアウト機能５５、およびＳＣＭ健全性確認機能５６を有する。

ＳＣＭ Ｉ／Ｆ機能２２は、ソース成果物操作クライアント１２の各機能５１〜５６に対応する、ソース成果物送受信対応機能６１、成果物一覧情報整合対応機能６２、変更点確認対応機能６３、コミット対応機能６４、チェックアウト対応機能６５、およびＳＣＭ健全性確認対応機能６６を有する。また、ＳＣＭ Ｉ／Ｆ機能２２は、ＳＣＭプラグインＩ／Ｆ６７、異常通知機能６８を有する。

ソース成果物操作クライアント１２の各機能５１〜５６と、ＳＣＭ Ｉ／Ｆ機能２２の各機能６１〜６６とは、ソフトウェア管理システム１により規定され標準化された機能である。また、ＳＣＭ Ｉ／Ｆ機能２２の各機能６２〜６６は、ソフトウェア構成管理システムに対して、ソフトウェア管理システム１において規定された要求を受け付ける要求対応部として機能する。

ＳＣＭプラグインＩ／Ｆ６７（インタフェース部）は、各機能６１〜６６とＳＣＭシステム２１とのインタフェース機能を有する。ＳＣＭプラグインＩ／Ｆ６７は、ソフトウェア管理システム１において規定し標準化された要求を、ＳＣＭシステム２１専用の要求に変換する。さらに、ＳＣＭシステム２１に要求を与えて得た実施結果をソフトウェア管理システム１に送信することができる。実施結果の送信においても、ソフトウェア管理システム１が受信することができる形式に変換を行うことができる。

ソース成果物操作クライアント１２の各機能５１〜５６は、開発者１１の要求に基づき、ＳＣＭ Ｉ／Ｆ機能２２の対応する各機能６１〜６６とそれぞれ通信する。

ソース成果物送受信機能５１は、ソース成果物送受信対応機能６１との間で、ソース成果物１３の送信、およびソース成果物一時コピー２３の受信を行う。成果物一覧情報整合機能５２は、成果物一覧情報整合対応機能６２に対して成果物情報整合要求を行う。成果物一覧情報整合対応機能６２は、ＳＣＭプラグインＩ／Ｆ６７を介して、ＳＣＭシステム２１に対して成果物情報整合要求を行う。成果物一覧情報整合対応機能６２は、実施結果をＳＣＭプラグインＩ／Ｆ６７より受け取り、成果物一覧情報整合機能５２へ通知する。

変更点確認機能５３は、変更点確認対応機能６３に対して変更点確認要求を行う。変更点確認対応機能６３は、ＳＣＭプラグインＩ／Ｆ６７を介して、ＳＣＭシステム２１に対して変更点確認要求を行う。変更点確認対応機能６３は、実施結果をＳＣＭプラグインＩ／Ｆ６７より受け取り、変更点確認機能５３へ通知する。

コミット機能５４は、コミット対応機能６４に対してコミット要求を行う。コミット対応機能６４は、ＳＣＭプラグインＩ／Ｆ６７を介して、ＳＣＭシステム２１に対してコミット要求を行う。コミット対応機能６４は、実施結果をＳＣＭプラグインＩ／Ｆ６７より受け取り、コミット機能５４へ通知する。

チェックアウト機能５５は、チェックアウト対応機能６５に対してチェックアウト要求を行う。チェックアウト対応機能６５は、ＳＣＭプラグインＩ／Ｆ６７を介してＳＣＭシステム２１に対しにチェックアウト要求を行う。チェックアウト対応機能６５は、実施結果をＳＣＭプラグインＩ／Ｆ６７より受け取り、チェックアウト機能５５へ通知する。

ＳＣＭ健全性確認機能５６は、ＳＣＭシステム２１の健全性を確認するため、ＳＣＭ健全性確認対応機能６６に対して情報整合要求、変更点確認要求、コミット要求、チェックアウト要求を行う。ＳＣＭ健全性確認対応機能６６（健全性確認部）は、ＳＣＭプラグインＩ／Ｆ６７を介して、健全性確認専用の模擬ファイルである模擬ソース成果物および模擬用リポジトリー（ＳＣＭシステム２１により管理される、マスターとなるソース成果物およびその保管場所）を使用した要求である健全性確認要求をＳＣＭプラグインＩ／Ｆ６７に対して行う。

ＳＣＭ健全性確認対応機能６６は、ＳＣＭ健全性確認機能５６から健全性確認要求を受信した場合のみならず、定期的（例えば１日１回）に要求を生成し健全性の定周期チェックを実施する。

健全性確認処理の結果、診断結果、すなわちＳＭＣシステム２１に問題がない場合、ＳＣＭ健全性確認対応機能６６は、チェック対象のＳＣＭプラグインＩ／Ｆ６７を有効状態にする。診断結果に問題が発見された場合、ＳＣＭ健全性確認対応機能６６は、ＳＣＭプラグインＩ／Ｆ６７を無効状態にし、異常通知機能６８にＳＣＭプラグインＩ／Ｆ６７が無効状態であること通知する。

異常通知機能６８（異常通知部）は、ＳＣＭプラグインＩ／Ｆ６７が無効状態であることが通知された場合、ＳＣＭプラグインＩ／Ｆ６７が無効状態になっていることをソフトウェア管理システム１外部である、異常通知機能６８に登録されている対象者（一般にはシステム管理者）に対してメールなどの通知手段により通知する。

変更点管理機能２５およびリリース管理機能２６は、ＳＣＭシステム２１より取得したい情報を、それぞれ変更点確認機能７１、チェックアウト機能７２を利用して取得する。その他の社内特有機能２７は、ＳＣＭシステム２１より取得したい情報を、変更点確認機能７３、チェックアウト機能７４を利用して取得する。

ソース成果物操作クライアント１２の変更点確認機能５３およびチェックアウト機能５５とＳＣＭ Ｉ／Ｆ機能２２の変更点確認対応機能６３およびチェックアウト対応機能６５との間で実行される処理と同様に、変更点確認機能７１、７３およびチェックアウト機能７２、７４は、変更点確認対応機能６３およびチェックアウト対応機能６５と通信を行い必要な情報を取得する。

本実施形態におけるソフトウェア管理システム１は、ソース成果物管理に最低限必要な、ソース成果物の送受信に必要な機能、登録／取り出しに必要な機能、変更点情報の取得に必要な機能を実現するための機能を備える一例である。ソフトウェア管理システム１は、ＳＣＭシステム２１が一般的に提供している上記以外の機能を備えてもよく、上記以外の機能を備える場合、各機能はＳＣＭ Ｉ／Ｆ機能２２を介してＳＣＭシステム２１と通信するようになっている。

次に、第１実施形態におけるソフトウェア管理システム１の動作について説明する。

以下、フローチャートを用いてＳＣＭ健全性確認対応機能６６がＳＣＭシステム２１の健全性を確認するための処理、およびＳＣＭプラグインＩ／Ｆ６７がソース成果物操作クライアント１２や変更点管理機能２５などから各種要求を受け取った場合に実行される処理を説明する。

図３は、ＳＣＭ健全性確認対応機能６６により実行されるＳＣＭ健全性確認処理を説明するフローチャートである。

ＳＣＭ健全性確認対応機能６６は、ＳＣＭ健全性確認機能５６または内部で一定周期で発生する健全性確認要求の受信待ちを行う（ステップＳ１）。要求を受信した場合、ＳＣＭ健全性確認対応機能６６は、ＳＣＭプラグインＩ／Ｆ６７に対して情報整合要求を指示し、ＳＣＭプラグインＩ／Ｆ６７はＳＣＭシステム２１に対して情報整合要求を実施する（ステップＳ２）。他の各種要求を受け付けた場合のＳＣＭプラグインＩ／Ｆ６７の動作については、図４で詳述する。

ＳＣＭ健全性確認対応機能６６は、予測されている診断結果が得られたかチェックする（ステップＳ３）。診断結果に問題がない場合（ステップＳ３の「問題なし」）、ＳＣＭ健全性確認対応機能６６は、ＳＣＭプラグインＩ／Ｆ６７に対して変更点確認要求を指示し、ＳＣＭプラグインＩ／Ｆ６７は変更点確認要求を実施する（ステップＳ４）。ＳＣＭ健全性確認対応機能６６は、予測されている診断結果が得られたかチェックする（ステップＳ５）。

診断結果に問題がない場合（ステップＳ５の「問題なし」）、ＳＣＭ健全性確認対応機能６６は、ＳＣＭプラグインＩ／Ｆ６７に対してコミット要求を指示し、ＳＣＭプラグインＩ／Ｆ６７はコミット要求を実施する（ステップＳ６）。ＳＣＭ健全性確認対応機能６６は、予測されている診断結果が得られたかチェックする（ステップＳ７）。診断結果に問題がない場合（ステップＳ７の「問題なし」）、ＳＣＭ健全性確認対応機能６６は、ＳＣＭプラグインＩ／Ｆ６７に対してチェックアウト要求を指示し、ＳＣＭプラグインＩ／Ｆ６７はチェックアウト要求を実施する（ステップＳ８）。

ＳＣＭ健全性確認対応機能６６は、予測されている診断結果が得られたかチェックする（ステップＳ９）。診断結果に問題がない場合（ステップＳ９の「問題なし」）、ＳＣＭ健全性確認対応機能６６は、健全性確認の対象となったＳＣＭプラグインＩ／Ｆ６７を有効状態にする（ステップＳ１０）。その後、処理はステップＳ１に戻り、健全性確認要求の受信待ちを行う。

一方、各診断結果に問題がある場合（ステップＳ３、Ｓ５、Ｓ７、Ｓ９の「問題あり」）、ＳＣＭ健全性確認対応機能６６は、健全性確認対象のＳＣＭプラグインＩ／Ｆ６７を無効状態にする（ステップＳ１１）。ＳＣＭ健全性確認対応機能６６は、異常通知機能６８にＳＣＭプラグインＩ／Ｆ６７が無効状態であること通知する（ステップＳ１２）。その後、ＳＣＭ健全性確認対応機能６６は、ステップＳ１に戻り健全性確認要求の受信待ちを行う。

図４は、第１実施形態におけるソフトウェア管理システム１のＳＭＣ Ｉ／Ｆ機能２２で実行される、ＳＣＭプラグインＩ／Ｆ６７が各種要求を受け取った場合に実行される要求実施処理を説明するフローチャートである。

図４においては、オープンソフトウェアとして提供されるＳＣＭシステムであるＢａｚａａｒを用いた場合のコマンドを実装例として説明する。なお、図４に示すコマンドのうち、「src_path」は、ソース成果物一時コピーの保存場所を示す。「msg」は、コミット時に残すメッセージを示す。「br_path」は、取り出したい成果物が入っているブランチのパスを示す。なお、Ｂａｚａａｒとは別のＳＣＭシステムが実装される場合は、このコマンドを相当の処理に置き換えることで同等の機能が提供される。

この処理は、各種機能より常時要求の受信待ちを行う（ステップＳ２１）。

要求を受信した場合、ＳＣＭプラグインＩ／Ｆ６７が有効状態であるか否かの判定が行われる（ステップＳ２２）。ＳＣＭプラグインＩ／Ｆ６７が無効状態であると判定された場合（ステップＳ２２のＮＯ）、ＳＣＭプラグインＩ／Ｆ６７から要求元にＳＣＭプラグインＩ／Ｆ６７が無効状態であることが通知され（ステップＳ２３）、処理は要求受信待ち状態に戻る（ステップＳ２１）。

ＳＣＭプラグインＩ／Ｆ６７が有効状態の場合（ステップＳ２２のＹＥＳ）、ＳＣＭプラグインＩ／Ｆ６７に対する要求内容のチェックが行われる（ステップＳ２４）。要求内容が成果物一覧情報整合機能５２（成果物一覧情報整合対応機能６２）からの成果物情報整合要求である場合、ＳＣＭプラグインＩ／Ｆ６７は、ＳＣＭシステム２１に対して情報整合用のコマンドを実行する（ステップＳ２５）。

要求内容が変更点確認機能５３（変更点確認対応機能６３）や変更点確認機能７１、７３からの変更点確認要求である場合、ＳＣＭプラグインＩ／Ｆ６７は、ＳＣＭシステム２１に対して変更点確認用のコマンドを実行する（ステップＳ２６）。

要求内容がコミット機能５４（コミット対応機能６４）からのコミット要求である場合、ＳＣＭプラグインＩ／Ｆ６７は、ＳＣＭシステム２１に対してコミット用のコマンドを実行する（ステップＳ２７）。

要求内容がチェックアウト機能５５（チェックアウト対応機能６５）や、チェックアウト機能７２、７４からのチェックアウト要求である場合、ＳＣＭプラグインＩ／Ｆ６７は、ＳＣＭシステムに対してチェックアウト用のコマンドを実行する（ステップＳ２８）。

ＳＣＭプラグインＩ／Ｆ６７は、ＳＣＭシステム２１の動作結果を要求元に返し（ステップＳ２９）、再度要求受信待ち状態（ステップＳ２１）に戻る。

第１実施形態のソフトウェア管理システム１によれば、開発者１１などの人間系によりソフトウェアアップデート機能２９におけるＳＣＭシステム２１のアップデートが実施された場合、ソフトウェア開発用ＰＣ２のＳＣＭ健全性確認機能５６がソフトウェア管理システム１のＳＣＭ健全性確認対応機能６６に対して健全性を確認するための要求を行う。また、ソフトウェア管理システム１内部においても、一定周期でＳＣＭシステム２１の健全性を確認するための要求を行う。

これにより、ソフトウェア管理システム１は、ソフトウェアのアップデートに起因するＳＣＭシステム２１の問題を検出することができる。

ＳＣＭシステム２１に問題がある場合、ソフトウェア管理システム１は、ＳＣＭプラグインＩ／Ｆ６７を無効状態にする。これによりソフトウェア管理システム１は、従来のソフトウェア管理システムにて想定される、アップデートに起因する品質低下が発生した状態での運用に対する課題を抑制することができる。

ソフトウェア管理システム１およびその管理方法は、ＳＣＭ Ｉ／Ｆ機能２２を設けることにより、ＳＣＭシステム２１の互換性の問題や、新たなＳＣＭシステム２１の採用によりソフトウェア管理システム１に改造が必要になった場合にも対処することができる。具体的には、ＳＣＭシステム２１の変更が生じた場合には、新たなＳＣＭシステム２１の仕様に合わせて、ＳＣＭプラグインＩ／Ｆ６７のＳＣＭシステム２１に対してコマンドを実行する部分のみを改造し、ＳＣＭプラグインＩ／Ｆ６７に対する要求に対する動作／応答に関してのみ検証を行うことで、品質を確保することができる。

また、ＳＣＭ Ｉ／Ｆ機能２２を設けるにあたり、従来から用いられるソフトウェア開発用ＰＣ２、変更点管理機能２５、リリース管理機能２６、その他の社内特有機能２７などに対しては、従来同等のＳＣＭシステム２１の機能を提供でき、さらに最終的な利用者３１に対しても従来システムの同様の機能を提供することができる。

このため、従来システムの問題であった変更点管理機能２５、リリース管理機能２６、その他の社内特有機能２７、およびＳＣＭシステム２１に付随して提供されるソース成果物操作クライアント１２に対する改造が発生せず、システム停止時間の短縮、改造・検証費用の抑制が可能となる。

［第２実施形態］
図５は、本発明の第２実施形態に係るソフトウェア管理システム１００のブロック構成図である。

図６は、第２実施形態におけるＳＣＭ Ｉ／Ｆ機能１２２の詳細な機能ブロック構成図である。

なお、第１実施形態と同一の構成には同一の符号を付し、重複する説明は省略する。また、図５および図６においては、説明の都合上、第１実施形態と対応する構成および部分の図示を省略する。

第２実施形態におけるソフトウェア管理システム１００が第１実施形態と異なる点は、２つ以上のＳＣＭシステム（第２実施形態においては３つのＳＣＭシステム１２１ａ〜１２１ｃ）が設けられる点である。これらのＳＣＭシステム１２１ａ〜１２１ｃは、それぞれ異なる種類のシステムソフトウェアを含むＳＣＭシステムである。

各ＳＣＭシステム１２１ａ〜１２１ｃには、優先度が付与されている。第２実施形態においては、ＳＣＭシステム１２１ａ、ＳＣＭシステム１２１ｂ、ＳＣＭシステム１２１ｃの順に高い優先度が付与される。優先度は、ソフトウェア開発用ＰＣ２や変更点管理機能２５などから送信される要求を実施する際に、優先的に利用されるＳＣＭシステムを判別するために利用される。

また、ソフトウェア管理システム１００は、各ＳＣＭシステム１２１ａ〜１２１ｃと同数のＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃを備え、各ＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃは各ＳＣＭシステム１２１ａ〜１２１ｃに対して専用に設けられる。

第２実施形態におけるソフトウェア管理システム１００の動作について説明する。第２実施形態におけるソフトウェア管理システム１００は、ＳＣＭ健全性確認対応機能１６６によりＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃに対して順番に健全性確認処理を行う。また、ソフトウェア管理システム１００は、健全性確認完了後、有効状態であるＳＣＭプラグインＩ／Ｆに対して、予め付与された優先度に応じて優先フラグをセットする。

以下、ソフトウェア管理システム１００のＳＣＭ健全性確認対応機能１６６により実行されるＳＣＭ健全性確認処理をフローチャートを用いて説明する。

図７は、第２実施形態におけるＳＣＭ健全性確認対応機能１６６により実行されるＳＣＭ健全性確認処理を説明するフローチャートである。
図８は、図７のＳＣＭ健全性確認処理の一部の処理を説明するフローチャートである。

ＳＣＭ健全性確認対応機能１６６は、ＳＣＭ健全性確認機能５６または内部で一定周期で発生する健全性確認要求の受信待ちを行う（ステップＳ３１）。要求を受信した場合、ＳＣＭ健全性確認対応機能１６６は、ＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃに対して順次各種要求を実施する（ステップＳ３２）。各種要求を受け付けた場合のＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃの動作については、図９で詳述する。

ステップＳ３３〜Ｓ４３の処理は、図４のＳＣＭ健全性確認処理の情報整合要求実施ステップＳ２〜無効状態通知ステップＳ１２とほぼ同様であるため、詳細な説明を省略する。

全てのＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃで各種要求の実施が完了した場合（ステップＳ３２の「全てで実施完了」）、図８に示すように、ＳＣＭ健全性確認対応機能１６６は、最も優先度の高いＳＣＭプラグインＩ／Ｆ１６７ａが有効状態であるか否かの判定を行う（ステップＳ４４）。ＳＣＭ健全性確認対応機能１６６は、ＳＣＭプラグインＩ／Ｆ１６７ａが有効状態であると判定した場合（ステップＳ４４のＹＥＳ）、ＳＣＭプラグインＩ／Ｆ１６７ａに優先フラグをセットする（ステップＳ４５）。

ＳＣＭ健全性確認対応機能１６６は、ＳＣＭプラグインＩ／Ｆ１６７ａが無効状態であると判断した場合（ステップＳ４４のＮＯ）、ＳＣＭ健全性確認対応機能１６６は、２番目に優先度の高いＳＣＭプラグインＩ／Ｆ１６７ｂが有効状態であるか否かの判定を行う（ステップＳ４６）。ＳＣＭ健全性確認対応機能１６６は、ＳＣＭプラグインＩ／Ｆ１６７ｂが有効状態であると判定した場合（ステップＳ４６のＹＥＳ）、ＳＣＭプラグインＩ／Ｆ１６７ｂに優先フラグをセットする（ステップＳ４７）。

ＳＣＭ健全性確認対応機能１６６は、ＳＣＭプラグインＩ／Ｆ１６７ｂが無効状態であると判断した場合（ステップＳ４６のＮＯ）、ＳＣＭ健全性確認対応機能１６６は、３番目に優先度の高いＳＣＭプラグインＩ／Ｆ１６７ｃが有効状態であるか否かの判定を行う（ステップＳ４８）。ＳＣＭ健全性確認対応機能１６６は、ＳＣＭプラグインＩ／Ｆ１６７ｃが有効状態であると判定した場合（ステップＳ４８のＹＥＳ）、ＳＣＭプラグインＩ／Ｆ１６７ｃに優先フラグをセットする（ステップＳ４９）。

ＳＣＭ健全性確認対応機能１６６は、ＳＣＭプラグインＩ／Ｆ１６７ｃが無効状態であると判断した場合（ステップＳ４８のＮＯ）、全てのＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃが無効状態であるため、全てのＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃにセットされている優先フラグをリセットする（ステップＳ５０）。優先フラグがセットまたはリセットされた後、処理は再び健全性確認要求の受信待ち状態（図７のステップＳ３１）に戻る。

次に、ＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｂが各種要求を受け取った場合にＳＣＭ Ｉ／Ｆ機能１２２で実行される処理について説明する。この要求実施処理は、各ＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃに対して同様に実施される。すなわち、成果物一覧情報整合対応機能６２などの各種機能から要求を受け取った場合、全てのＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃに対して同じ要求を送信する。

図９は、第２実施形態におけるソフトウェア管理システム１００のＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃが各種要求を受け取った場合に実行される要求実施処理を説明するフローチャートである。

ＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃの処理においては、ＳＣＭシステム１２１ａ〜１２１ｃの種類が異なるため、各要求に対して実施されるコマンド実行処理がシステム間で異なる。図９においては、オープンソフトウェアとして提供されるＳＣＭシステムであるＢａｚａａｒを用いた場合のコマンドを実装例として説明する。例えば、他のＳＣＭシステムにＢａｚａａｒ同様のオープンソースソフトウェアとして提供されているＭｅｒｃｕｒｉａｌを用いる場合、情報整合用のコマンドは「hg add src_path」のように異なるものとなる。

各ＳＣＭシステム１２１ａ〜１２１ｃに用いられるソフトウェアの種類に応じてコマンドが異なる点以外は、各ＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃで実行される処理はほぼ同様であるため、本処理の説明においては、ＳＣＭシステム１２１ａ〜１２１ｃを単にＳＣＭシステム１２１とし、ＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃを単にＳＣＭプラグインＩ／Ｆ１６７として説明する。

ステップＳ６１〜Ｓ６４は、図４の要求受信待ちステップＳ２１〜要求チェックステップＳ２４とほぼ同様であるため、ここでは説明を省略する。

要求内容が成果物一覧情報整合対応機能６２などからの成果物情報整合要求である場合、ＳＣＭプラグインＩ／Ｆ１６７は、ＳＣＭシステム１２１に対して情報整合用のコマンドを実行する（ステップＳ６５）。要求内容が変更点確認対応機能６３などからの変更点確認要求である場合、ＳＣＭプラグインＩ／Ｆ１６７に対して優先フラグがセットされているか否かの判定が行われる（ステップＳ６６）。ＳＣＭプラグインＩ／Ｆ１６７に対して優先フラグがセットされていると判定された場合（ステップＳ６６のＹＥＳ）、ＳＣＭプラグインＩ／Ｆ１６７は、ＳＣＭシステム１２１に対して変更点確認用のコマンドを実行する（ステップＳ６７）。

要求内容がコミット対応機能６４からのコミット要求である場合、ＳＣＭプラグインＩ／Ｆ１６７は、ＳＣＭシステム１２１に対してコミット用のコマンドを実行する（ステップＳ６８）。要求内容がチェックアウト対応機能６５などからのチェックアウト要求である場合、ＳＣＭプラグインＩ／Ｆ１６７に対して優先フラグがセットされているか否かの判定が行われる（ステップＳ６９）。

ＳＣＭプラグインＩ／Ｆ１６７に対して優先フラグがセットされていると判定された場合（ステップＳ６９のＹＥＳ）、ＳＣＭプラグインＩ／Ｆ１６７は、ＳＣＭシステム１２１に対してチェックアウト用のコマンドを実行する（ステップＳ７０）。ＳＣＭプラグインＩ／Ｆ１６７は、ＳＣＭシステム１２１の動作結果を要求元に返し（ステップＳ７１）、再度要求受信待ち状態（ステップＳ６１）に戻る。

一方、ＳＣＭプラグインＩ／Ｆ１６７に優先フラグがセットされていないと判定された場合（ステップＳ６６、Ｓ６９のＮＯ）、要求元にＳＣＭプラグインＩ／Ｆ１６７が無効状態であることを通知し（ステップＳ６３）、要求受信待ち状態に戻る（ステップＳ６１）。

図９の要求実施処理においては、ＳＣＭプラグインＩ／Ｆ１６７に対して変更点確認要求またはチェックアウト要求があった場合、各要求に対するコマンドの実行前に、要求対象となるＳＣＭプラグインＩ／Ｆ１６７に優先フラグがセットされているか否かの判定が行われる。優先フラグがセットされている場合には、各要求に対する処理が実行される。一方、優先フラグがリセットされている場合には、ＳＣＭプラグインＩ／Ｆ１６７が無効状態である場合と同じ動作（ステップＳ６３）を行う。

すなわち、この要求実施処理は、ＳＣＭシステム１２１へソース成果物一時コピー２３を登録する方向の要求である、成果物情報整合要求、コミット要求に対しては要求の実施は制限しない。一方、ＳＣＭシステム１２１より情報を取り出す方向の要求に対しては、有効状態であり、かつ、優先フラグがセットされている（最も優先度の高い）ＳＣＭプラグインＩ／Ｆ１６７だけが処理を行う。

優先フラグは、２つ以上のＳＣＭプラグインＩ／Ｆ１６７に同時にセットされることはないので、有効状態のＳＣＭプラグインＩ／Ｆ１６７が複数存在していても、１つのＳＣＭプラグインＩ／Ｆ１６７から情報が返されるようになっている。

第２実施形態のソフトウェア管理システム１００によれば、複数のＳＣＭシステム１２１ａ〜１２１ｃに対してソース成果物１３の登録を実施する一方、情報の取り出しは、有効状態かつ優先度の高いＳＣＭシステム１２１ａ〜１２１ｃから行うことができる。

例えば、アップデートに起因する品質低下が発生する場合、複数の種類の異なるＳＣＭシステム１２１ａ〜１２１ｃに対して同時に問題が発生する可能性は非常に低いと考えられるため、非常に高い可用性が実現できる。また、同一種類の場合は、ソフトウェア管理システム１００が多重化され、高い信用性を実現することができる。

なお、ソフトウェア管理システム１００の信頼性をより向上させるため、ＳＣＭ健全性確認処理のフラグリセットステップＳ５０（図８）において、全ての優先フラグがリセットされた場合に以下の図１０のＳＣＭ健全性確認処理を実行してもよい。図１０のＳＣＭ健全性確認処理は、多数決論理を適用するため、ＳＣＭシステム（ＳＣＭプラグインＩ／Ｆ）が３つ以上ある場合に適用可能である。

図１０は、図７、図８のＳＣＭ健全性確認処理のフラグリセットステップＳ５０に続くＳＣＭ健全性確認処理を説明するフローチャートである。

ＳＣＭ健全性確認対応機能１６６は、各ＳＣＭプラグインＩ／Ｆ１６７ａ〜１６７ｃ（ＳＣＭプラグインＩ／Ｆ１６７）に対して、それぞれ変更点確認要求を実施する。ここでは、図７の変更点確認要求（ステップＳ３５）とは異なり、実際のリポジトリーに対して要求が実施される。ＳＣＭ健全性確認対応機能１６６は、各ＳＣＭシステム１２１ａ〜１２１ｃ（ＳＣＭシステム１２１）から得られた結果を記憶する（ステップＳ７１）。

ＳＣＭ健全性確認対応機能１６６は、得られた結果を比較する（ステップＳ７２）。ＳＣＭ健全性確認対応機能１６６は、比較結果に多数決の論理を適用し、ＳＣＭプラグインＩ／Ｆ１６７のうち他の２つのＳＣＭプラグインＩ／Ｆ１６７とは不一致である結果を返したＳＣＭプラグインＩ／Ｆ１６７を異常とみなし、無効状態にする（ステップＳ７３）。なお、ＳＣＭプラグインＩ／Ｆが偶数個設けられる場合には多数決論理が適用できない場合がある。この場合、多数決論理のほか、予めＳＣＭプラグインＩ／Ｆ１６７に付与された優先度などを考慮して、有効状態か無効状態かを判定することができる。

ＳＣＭ健全性確認対応機能１６６は、全ての結果が不一致である場合には、全てのＳＣＭプラグインＩ／Ｆ１６７を無効状態にする（ステップＳ７４）。ＳＣＭ健全性確認対応機能１６６は、全ての結果が一致する場合には、各ＳＣＭプラグインＩ／Ｆ１６７に対してチェックアウト要求を実施する。ここでは、図７のチェックアウト要求（ステップＳ３９）とは異なり、実際のリポジトリーに対してチェックアウト要求が実施される。ＳＣＭ健全性確認対応機能１６６は、各ＳＣＭシステム１２１から得られた結果を記憶する（ステップＳ７５）。

ＳＣＭ健全性確認対応機能１６６は、得られた結果を比較する（ステップＳ７６）。ＳＣＭ健全性確認対応機能１６６は、変更点確認要求を行う場合と同様に、ＳＣＭプラグインＩ／Ｆ１６７のうち他の２つのＳＣＭプラグインＩ／Ｆ１６７とは不一致である結果を返したＳＣＭプラグインＩ／Ｆ１６７を異常とみなし、無効状態にする（ステップＳ７７）。ＳＣＭ健全性確認対応機能１６６は、全ての結果が不一致である場合には、全てのＳＣＭプラグインＩ／Ｆ１６７を無効状態にする（ステップＳ７８）。

ＳＣＭ健全性確認対応機能１６６は、ＳＣＭプラグインＩ／Ｆ１６７を無効状態にした場合には、異常通知機能６８にＳＣＭプラグインＩ／Ｆ１６７が無効状態であること通知する（ステップＳ７９）。

ＳＣＭ健全性確認対応機能１６６は、チェックアウト要求の全ての結果が一致する場合（ステップＳ７６の「全てのＳＣＭプラグインＩ／Ｆが一致」）、またはＳＣＭプラグインＩ／Ｆの無効状態を通知した（ステップＳ７９）後、図７の要求受信待ちステップＳ３１に戻り健全性確認要求の受信待ちを行う。

この図１０のＳＣＭ健全性確認処理によれば、模擬ソース成果物および模擬リポジトリーを使用してＳＣＭシステム１２１ａ〜１２１ｃ単体の異常を検出する方法では検出しきれない問題を、多数決論理で検出することにより、より信頼性の高いソフトウェア管理システム１００を実現できる。

［第３実施形態］
図１１は、第３実施形態におけるＳＣＭ Ｉ／Ｆ機能２２２の詳細な機能ブロック構成図である。第１および第２実施形態と同一の構成には同一の符号を付し、重複する説明は省略する。また、図１１においては、説明の都合上、第１および第２実施形態と対応する構成および部分の図示を省略する。

なお、ソフトウェア管理システム２００全体のブロック構成図については、図５とほぼ同様であるため図面を用いた説明を省略する。

第３実施形態におけるソフトウェア管理システム２００が、第２実施形態と異なる点は、データ自動復元機能２６９が追加された点である。データ自動復元機能２６９（自動復元部）は、ＳＣＭ健全性確認対応機能２６６により無効状態にされたＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃを監視する。データ自動復元機能２６９は、有効状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃ経由で取得したソース成果物から無効状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対応するＳＣＭシステム１２１ａ〜１２１ｃを復元する。

以下、無効状態であるＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対するデータ自動復元機能２６９の処理について、フローチャートを用いて説明する。

図１２は、第３実施形態におけるソフトウェア管理システム２００のデータ自動復元機能２６９により実行されるデータ自動復元処理を説明するフローチャートである。

データ自動復元機能２６９は、一定周期（例えば１分周期）でデータ自動復元処理を繰り返す（ステップＳ８１）。データ自動復元機能２６９は、無効状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃがあるかチェックする（ステップＳ８２）。無効状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃがない場合（ステップＳ８２の「なし」）、ステップＳ８１に戻り次の周期が到来するまで待機する。無効状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃがある場合（ステップＳ８２の「あり」）、データ自動復元機能２６９は、有効状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃがあるかチェックする（ステップＳ８３）。有効状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃがない場合（ステップＳ８３の「なし」）、ステップＳ８１に戻り次の周期が到来するまで待機する。

有効状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃがある場合（ステップＳ８３の「あり」）、データ自動復元機能２６９は、無効状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに復元中状態をセットする（ステップＳ８４）。データ自動復元機能２６９は、有効状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対してチェックアウト要求を実施し、ソース成果物を復元用ファイルとして取得する（ステップＳ８５）。

データ自動復元機能２６９は、復元中状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対して、取得したソース成果物用の成果物情報整合要求を実施する（ステップＳ８６）。また、データ自動復元機能２６９は、復元中状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対して、取得したソース成果物用のコミット要求を実施する（ステップＳ８７）。

データ自動復元機能２６９は、復元中状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃ（ＳＣＭシステム１２１ａ〜１２１ｃ）に対して全てのソース成果物を復元したか否かを判定する（ステップＳ８８）。全てのソース成果物が復元されていない場合（ステップＳ８８のＮＯ）、全ての成果物が復元されるまでチェックアウト要求ステップＳ８５〜復元判定ステップＳ８８を繰り返す。

全てのソース成果物が復元された場合（ステップＳ８８のＹＥＳ）、データ自動復元機能２６９は、ＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃの復元中状態をリセットする（ステップＳ８９）。処理はステップＳ８１に戻り、次の周期が到来するまで待機する。

次に、データ自動復元機能２６９の要求に基づいてＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃが実行する要求実施処理についてフローチャートを用いて説明する。

図１３は、第３実施形態におけるソフトウェア管理システム２００のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃが各種要求を受け取った場合に実行される要求実施処理を説明するフローチャートである。

ステップＳ９１およびＳ９２は、図９の要求受信待ちステップＳ６１および要求チェックステップＳ６２とほぼ同様であるため、ここでは説明を省略する。対象となるＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃが有効状態である場合（ステップＳ９２のＹＥＳ）、以降の処理は第２実施形態の図９の要求実施処理のコマンド実行ステップＳ６５〜結果送信ステップＳ７１とほぼ同様であるためここでは説明を省略する。

要求の対象となるＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃが有効状態ではない場合（ステップＳ９２のＮＯ）、要求は復元中状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対してであり、かつデータ自動復元機能２６９からの要求であるか否かの判定が行われる（ステップＳ９３）。要求は復元中状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対してではなく、またはデータ自動復元機能２６９からの要求ではない場合（ステップＳ９３のＮＯ）、要求元に対象となるＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃは無効状態であることが通知され（ステップＳ９４）、処理は要求受信待ち状態に戻る（ステップＳ９１）。

要求は復元中状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対してであり、かつデータ自動復元機能２６９からの要求である場合（ステップＳ９３のＹＥＳ）、ＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対する要求内容のチェックが行われる（ステップＳ９５）。

この場合、図１２のデータ自動復元処理で説明したように、データ自動復元機能２６９は、いずれかの有効状態であるＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対してチェックアウト要求を行う。また、データ自動復元機能２６９は、復元中状態のＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対して、取得されたソース成果物用の情報整合要求およびコミット要求、すなわち、ソース成果物を登録する方向の要求を行う。ＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃは、データ自動復元機能２６９から送信される要求に対して所定のコマンドを実行する。

すなわち、受信した要求が、復元中状態であるＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃに対するデータ自動復元機能２６９からの要求である場合には、ＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃが無効状態の場合であっても受信した要求の処理が実施される。以降の処理は第１および第２実施形態と同様であるため、ここでは説明を省略する。

第３実施形態におけるソフトウェア管理システム２００によれば、異常検出されたＳＣＭプラグインＩ／Ｆ２６７ａ〜２６７ｃおよびＳＣＭシステム１２１ａ〜１２１ｃを自動的に復旧できる可能性があり、より可用性の高いソフトウェア管理システムを実現できる。

このソフトウェア管理システム２００は、第２実施形態で説明した多数決論理において検出されるＳＣＭシステム１２１ａ〜１２１ｃの異常に起因する問題ではなく、ソフトウェア管理システム内の記憶装置の異常などに起因する、登録されているソース成果物データの異常などが発生している場合において、特に有効である。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１、１００、２００ ソフトウェア管理システム
２ ソフトウェア開発用パーソナルコンピュータ（ＰＣ）
１２ ソース成果物操作クライアント
１３ ソース成果物
２１、１２１ａ〜１２１ｃ ソフトウェア構成管理システム（ＳＣＭシステム）
２２、１２２、２２２ ＳＣＭインタフェース機能（ＳＣＭ Ｉ／Ｆ機能）
２３ ソース成果物一時コピー
２５ 変更点管理機能
２６ リリース管理機能
２７ その他の社内特有機能
２９ ソフトウェアアップデート機能
５１ ソース成果物送受信機能
５２ 成果物一覧情報整合機能
５３ 変更点確認機能
５４ コミット機能
５５ チェックアウト機能
５６ ＳＣＭ健全性確認機能
６１ ソース成果物送受信対応機能
６２ 成果物一覧情報整合対応機能
６３ 変更点確認対応機能
６４ コミット対応機能
６５ チェックアウト対応機能
６６、１６６、２６６ ＳＣＭ健全性確認対応機能
６７、１６７ａ〜１６７ｃ、２６７ａ〜２６７ｃ ＳＣＭプラグインＩ／Ｆ
６８ 異常通知機能
７１、７３ 変更点確認機能
７２、７４ チェックアウト機能
２６９ データ自動復元機能

Claims (10)

1. ソフトウェア開発に係るファイルの変更履歴を含むファイル管理を行うためのサーバシステムであるソフトウェア管理システムにおいて、
   前記ファイル管理を行うソフトウェア構成管理システムと、
   前記ソフトウェア管理システムにおいて規定された要求を受け付ける要求対応部と、
   前記要求対応部が受け付けた前記要求を、前記ソフトウェア構成管理システムが専用に受け付ける要求に変換し、前記要求対応部と前記ソフトウェア構成管理システムとのインタフェース機能を有するインタフェース部とを備えたことを特徴とするソフトウェア管理システム。
2. 前記ソフトウェア構成管理システムの健全性を確認する健全性確認要求を前記インタフェース部に送信し、前記健全性確認要求に対して前記ソフトウェア構成管理システムから得られる結果に基づいて前記ソフトウェア構成管理システムの健全性を診断し、前記結果に問題がある場合前記インタフェース部を無効状態にし、前記結果に問題がない場合前記インタフェース部を有効状態にする健全性確認部をさらに備えた請求項１記載のソフトウェア管理システム。
3. 健全性確認要求は、前記ソフトウェア構成管理システムが管理するファイルとは異なる健全性確認用の模擬ファイルを用いて実施される請求項２記載のソフトウェア管理システム。
4. 前記健全性確認部が前記インタフェースを無効状態にした場合、前記インタフェース部が無効状態である旨の通知を前記ソフトウェア管理システム外部に通知する異常通知部をさらに備えた請求項２記載のソフトウェア管理システム。
5. 前記インタフェース部は前記無効状態である場合、前記要求を行った前記要求対応部に対して無効状態である旨を通知する請求項２記載のソフトウェア管理システム。
6. 前記ソフトウェア構成管理システムは、２つ以上設けられ、
   前記インタフェース部は前記ソフトウェア構成管理システムの数と同数設けられ、各インタフェース部は各前記ソフトウェア構成管理システムに対して専用に設けられ、
   各前記ソフトウェア構成管理システムには、優先的に利用されるソフトウェア構成管理システムを判別するために利用される優先度が予め付与され、
   前記要求は、前記有効状態であるインタフェース部のうち、最も優先度の高いインタフェース部に対して送信される請求項２記載のソフトウェア管理システム。
7. 最も優先度の高いソフトウェア構成管理システムに対応するインタフェース部に対して送信される要求は、前記ソフトウェア構成管理システムより所定のファイルを取り出す方向の要求である請求項６記載のソフトウェア管理システム。
8. 前記ソフトウェア構成管理システムは、３つ以上設けられ、
   前記インタフェース部は前記ソフトウェア構成管理システムの数と同数設けられ、各インタフェース部は各前記ソフトウェア構成管理システムに対して専用に設けられ、
   前記健全性確認部は、前記健全性確認要求に対して前記ソフトウェア構成管理システムより得られる結果に多数決論理を適用して、前記ソフトウェア構成管理システムの健全性を診断する請求項２記載のソフトウェア管理システム。
9. 無効状態であるインタフェース部と有効状態であるインタフェース部とが存在する場合、有効状態のインタフェース部に対し所定のファイルを復元用ファイルとして取り出す要求を行い、得られた前記復元用ファイルを用いて前記無効状態のインタフェース部に対して前記復元用ファイルを登録する方向の要求を行う自動復元部をさらに備えた請求項２記載のソフトウェア管理システム。
10. ソフトウェア開発に係るファイルの変更履歴を含むファイル管理を行うためのサーバシステムであるソフトウェア管理方法において、
    前記ソフトウェア管理システムにおいて規定された要求を受け付け、
    前記要求を前記ファイル管理を行うソフトウェア構成管理システムが専用に受け付ける要求に変換し、
    前記変換された要求を前記ソフトウェア構成管理システムに送信し、
    前記ソフトウェア構成管理システムから得られる前記要求に対する結果を前記要求の要求元に送信するソフトウェア管理方法。

Images