成果物管理サーバ、成果物管理方法及びプログラム
【課題】システム開発における成果物の変更が生じた場合に、その変更により発生する手戻り作業における成果物の不整合を軽減する。
【解決手段】工程毎に作成される成果物を管理する成果物管理サーバ１であって、各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部と、成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出する成果物変更監視部と、前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信する成果物変更通知部と、を備える。
【解決手段】工程毎に作成される成果物を管理する成果物管理サーバ１であって、各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部と、成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出する成果物変更監視部と、前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信する成果物変更通知部と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、成果物管理サーバ、成果物管理方法及びプログラムに関する。
【背景技術】
【０００２】
一般に、システム開発では、各工程における成果物（要件定義書、基本設計書、詳細設計書、関数定義など）は、前の工程の成果物に基づいて作成される。例えば、基本設計書は前の工程の成果物である要件定義書に基づいて作成される。
ところで、これらの成果物は、様々な要因から頻繁に変更が発生する。その場合に、この変更により影響がある成果物を修正する手戻り作業が生じる。例えば、ある成果物に変更が発生した場合には、工程を一つずつ戻り、当該成果物より前の工程で作成された成果物（以下、前成果物とする）に対して影響があれば、その前成果物を更新する必要がある。しかしながら、実際のシステム開発では各成果物が１対１に対応しているわけではなく、複数の文書間に関連が存在する。
特許文献１に記載された技術では、ある成果物の変更がどの成果物に影響が及ぶかを予め設定（リンク付け）しておき、実際に変更が生じた場合の影響範囲（影響する成果物）を特定している。
【０００３】
図１３は、成果物の変更により発生する手戻り作業の一例を示した概略図である。
この図に示す例では、要件定義書Ａに基づいて基本設計書Ｂが作成されている。また、基本設計書Ｂに基づいて詳細設計書Ｃ及び詳細設計書Ｄが作成されている。また、関数定義書Ｅは、詳細設計書Ｃ及び詳細設計書Ｄに基づいて作成されている。
ここで、関数定義書Ｅにおいて、採用ＯＳをＷｉｎｄｏｗｓ（登録商標）からＬｉｎｕｘに、使用言語をＪａｖａ（登録商標）からＣ言語に変更した場合について説明する。
この変更を受けて、詳細設計書Ｃでは採用ＯＳと使用言語を変更する必要がある。また、詳細設計書Ｄでは採用ＯＳと使用言語に加えて、採用ＤＢをＭｙＳＱＬからＤＢ２に変更する必要がある。これにより、基本設計書Ｂでは、詳細設計書Ｃと詳細設計書Ｄの変更の影響を受けて、採用ＯＳ、使用言語及び採用ＤＢを変更する必要がある。
基本設計書Ｂは、当該成果物より後の工程で作成された成果物（以下、後成果物とする）が複数存在する。そのため、基本設計書Ｂには複数の成果物（詳細設計書Ｃ及び詳細設計書Ｄ）の変更の影響が及ぶ。以降では、基本設計書Ｂのような後成果物が複数存在する成果物のことを分岐元成果物と呼ぶ。
上述した例では、詳細設計書Ｃと詳細設計書Ｄの変更が完了した後、基本設計書Ｂに対する変更が行われなければならない。もし、詳細設計書Ｃの変更だけが完了している状況で、基本設計書Ｂを変更してしまうと、詳細設計書Ｄの変更の影響を加味することができず、基本設計書Ｂにおける採用ＤＢの変更が抜けてしまう、という成果物の不整合が生じる。
【特許文献１】特開２００７−１８３３４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載された技術では、成果物の変更により発生する手戻り作業における成果物の変更順序については考慮していないため、上述したような成果物の不整合が生じる可能性がある、という問題がある。
本発明は上記の点に鑑みてなされたものであり、その目的は、システム開発における成果物の変更が生じた場合に、その変更により発生する手戻り作業における成果物の不整合を軽減することができる成果物管理サーバ、成果物管理方法及びプログラムを提供することにある。
【課題を解決するための手段】
【０００５】
本発明は上記の課題を解決するためになされたものであり、本発明の一態様は、工程毎に作成される成果物を管理する成果物管理サーバであって、各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部と、成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出する成果物変更監視部と、前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信する成果物変更通知部と、を備えることを特徴とする成果物管理サーバ
【０００６】
また、本発明の一態様は、上記の成果物管理サーバにおいて、前記成果物更新監視部は、さらに、変更有りと確認された成果物が、前記成果物変更通知部が送信した確認依頼に基づいて変更された成果物だった場合、前記成果物記憶部から新たに修正の確認をすべき成果物を抽出し、確認順序情報を更新することを特徴とする。
【０００７】
また、本発明の一態様は、上記の成果物管理サーバにおいて、前記成果物更新監視部は、変更が生じた成果物を基点として、前工程の成果物を順次遡って抽出した後に、後工程の成果物を工程に沿って順次抽出する事を特徴とする。
【０００８】
また、本発明の一態様は、上記の成果物管理サーバにおいて、前記成果物情報記憶部は、さらに、成果物と、当該成果物と前後関係にある成果物との関係の重要度を記憶し、前記成果物更新監視部は前記重要度に基づいて確認順序情報を抽出することを特徴とする。
【０００９】
また、本発明の一態様は、工程毎に作成される成果物を管理する成果物管理方法であって各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部を備える成果物管理サーバが、成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出するステップと、前記成果物管理サーバが、前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信するステップと、を有することを特徴とする成果物管理方法である。
【００１０】
工程毎に作成される成果物を管理するためのプログラムであって、各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部を備えるコンピュータに、成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出するステップと、前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信するステップと、を実行させるためのプログラムである。
【発明の効果】
【００１１】
本発明によれば、各工程で作成される成果物の工程間の前後関係を記憶し、成果物の変更が生じると、当該成果物の変更を修正すべき成果物を更新すべき順に抽出するので、作業者は抽出された順に従って成果物を更新することができる。これにより、システム開発における成果物の変更が生じた場合に、その変更により発生する手戻り作業における成果物の不整合を軽減することができる。また、成果物の不整合による再度の手戻り作業を抑制することができる。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照しながら本発明の実施形態について詳しく説明する。
［第１の実施形態］
図１は、本発明の実施形態による成果物管理システムの構成を示すブロック図である。成果物管理システムは、成果物管理サーバ１と複数の利用者端末２から構成される。利用者端末２は成果物の作成又は更新を行う作業者が利用する端末である。利用者端末２は、成果物を編集する文書編集部２１を含んで構成される。
成果物管理サーバ１は、成果物管理部１１と、成果物更新監視部１２と、成果物変更通知部１３と、作業者ＤＢ（データベース）１４と、成果物管理ＤＢ（データベース）１５（成果物管理情報記憶部）と、成果物記憶部１６と、履歴ＤＢ（データベース）１７と、確認順序ＤＢ（データベース）１８と、を含んで構成される。
【００１３】
成果物管理部１１は、システム開発における各工程で生成された成果物を管理する。本実施形態では、成果物は、要件定義書、基本設計書、詳細設計書及び関数定義書などの各工程において生成されるドキュメントである。成果物管理部１１は、利用者端末２から成果物とともに新規成果物登録要求を受信すると、受信した成果物を成果物記憶部１６に記憶する。このとき、成果物管理部１１は、成果物を一意に識別する成果物ＩＤを生成し、記憶した成果物と対応付けて成果物管理ＤＢ１５に記憶する。また、成果物管理部１１は、利用者端末２から成果物とともに成果物更新要求を受信すると、受信した成果物を成果物記憶部１６に記憶する。このとき、成果物管理部１１は、成果物管理ＤＢ１５の成果物更新要求に含まれる成果物ＩＤに対応する成果物を新たに記憶した成果物に置き換える。
【００１４】
成果物更新監視部１２は、成果物の更新状況を管理する。成果物更新監視部１２は、成果物の変更が生じると、前記成果物の変更に影響する成果物を成果物間の関連に基づいて更新すべき順に抽出する。また、成果物更新監視部１２は、抽出した成果物が作業者の確認済みか否かを示す確認順序テーブル（確認順序情報）を生成して確認順序ＤＢ１８に記憶する。成果物変更通知部１３は、確認順序ＤＢ１８が更新されると、確認順序テーブルに基づいて利用者端末２に成果物変更通知を送信する。
【００１５】
図２は、本実施形態における成果物の関連の一例を示す概略図である。
この図に示す成果物Ａ００１〜Ａ００９は成果物記憶部１６に記憶されている。この図に示す例では、成果物Ａ００１の後成果物は成果物Ａ００２及び成果物Ａ００３である。成果物Ａ００２の前成果物は成果物Ａ００１であり、後成果物は成果物Ａ００４である。成果物Ａ００３の前成果物は成果物Ａ００１であり、後成果物は成果物Ａ００４及び成果物Ａ００５である。成果物Ａ００４の前成果物は成果物Ａ００２及び成果物Ａ００３であり、後成果物は成果物Ａ００６及び成果物Ａ００７である。成果物Ａ００５の前成果物は成果物Ａ００３であり、後成果物はない。成果物Ａ００６の前成果物は成果物Ａ００４であり、後成果物はない。成果物Ａ００７の前成果物は成果物Ａ００４であり、後成果物は成果物Ａ００８及び成果物Ａ００９である。成果物Ａ００８の前成果物は成果物Ａ００７であり、後成果物はない。成果物Ａ００９の前成果物は成果物Ａ００７であり、後成果物はない。
【００１６】
図３は、本実施形態における作業者ＤＢ１４に記憶される作業者テーブルのデータ構造及びデータ例を示す概略図である。
図示するように、作業者テーブルは、行と列からなる２次元の表形式のデータであり、ユーザＩＤと、メールアドレスと、所属グループＩＤと、の各項目の列を有している。この作業者テーブルの主キーは、ユーザＩＤである。作業者テーブルの各行は作業者毎に存在する。ユーザＩＤは、作業者を一意に識別するための識別番号である。メールアドレスは、作業者のメールアドレスである。所属グループＩＤは、作業者が所属するグループの識別番号である。
【００１７】
図４は、本実施形態における成果物管理ＤＢ１５に記憶される成果物管理テーブルのデータ構造及びデータ例を示す概略図である。
成果物管理テーブルは、システム開発における各成果物が生成される工程の前後関係を記憶する。図示するように、成果物管理テーブルは、行と列からなる２次元の表形式のデータであり、成果物ＩＤと、前成果物ＩＤと、後成果物ＩＤと、パスと、作成者と、変更日時と、の各項目の列を有している。この成果物管理テーブルの主キーは成果物ＩＤである。成果物管理テーブルの各行は成果物毎に存在する。成果物ＩＤは、成果物を一意に識別するための識別番号である。前成果物ＩＤは、前成果物の成果物ＩＤである。後成果物ＩＤは、後成果物の成果物ＩＤである。パスは、成果物が格納されているアドレスである。作成者は、成果物の作成者のユーザＩＤである。変更日時は、成果物を更新した日時である。なお、前成果物ＩＤ及び後成果物ＩＤの欄において、「ｎｕｌｌ」は、該当する成果物が存在しないことを表す。
【００１８】
図５は、本実施形態における履歴ＤＢ１７に記憶される履歴テーブルのデータ構造及びデータ例を示す概略図である。
履歴テーブルは、成果物の更新履歴を記録するテーブルである。図示するように、履歴テーブルは、行と列からなる２次元の表形式のデータであり、変更識別ＩＤと、成果物ＩＤと、パスと、変更日時と、の各項目の列を有している。変更識別ＩＤは、更新内容を一意に識別するための識別番号である。成果物ＩＤは、更新された成果物の成果物ＩＤである。パスは、更新された成果物を記憶しているアドレスである。変更日時は、成果物が更新された日時である。
【００１９】
図６は、本実施形態における確認順序ＤＢ１８に記憶される確認順序テーブルのデータ構造及びデータ例を示す概略図である。
確認順序テーブルは、成果物が変更されると成果物更新監視部１２により生成されるテーブルである。図示するように、確認順序テーブルは、行と列からなる２次元の表形式のデータであり、成果物ＩＤと、リンク元成果物ＩＤと、向きと、確認済みフラグと、の各項目の列を有している。この確認順序テーブルの主キーは成果物ＩＤである。確認順序テーブルの各行は成果物毎に存在する。リンク元成果物ＩＤは、変更された成果物から当該成果物へ繋がるリンクにおける直前の成果物の成果物ＩＤである。向きは、当該成果物がリンク元成果物に対して前成果物であるか後成果物であるかを示す。「ｐｒｅ」は、当該成果物がリンク元成果物の前成果物であることを表す。「ｐｏｓｔ」は、当該成果物がリンク元成果物の後成果物であることを表す。確認フラグは、当該成果物を作業者が確認済みであるか否かを示すフラグである。確認フラグが「ＯＮ」になると作業者が確認したことを表す。なお、図では、確認フラグが「ＯＮ」であることを「○」で表す。
【００２０】
図７は、本実施形態における成果物管理サーバ１の成果物登録処理の流れを示すフローチャートである。
利用者端末２は、作業者によって作成された成果物を新規成果物登録要求とともにネットワークを介して成果物管理サーバ１に送信する。図７に示す処理は、成果物管理サーバ１が成果物とともに新規成果物登録要求を受信するとスタートする。新規成果物登録要求は、新たに作成した成果物の登録要求である。
まず、ステップＳ１では、成果物管理部１１が、利用者端末２に受信した成果物の前成果物ＩＤ及び作業者のユーザＩＤを要求する。具体的には、成果物管理部１１は、利用者端末２の画面に前成果物ＩＤ及びユーザＩＤの入力画面を表示する。このとき、成果物管理部１１は、成果物管理ＤＢ１５の成果物管理テーブルから全ての成果物ＩＤを読み出して、その一覧を利用者端末２の画面に表示してもよい。これにより、利用者端末２は、一覧から前成果物ＩＤを選択することが可能になる。
次のステップＳ２では、成果物管理部１１が、利用者端末２から前成果物ＩＤ及びユーザＩＤを受信したか否かを判定する。前成果物ＩＤ及びユーザＩＤを受信すると、次のステップＳ３に進む。一方、受信していない場合には、ステップＳ２に戻る。
【００２１】
次のステップＳ３では、成果物管理部１１が、受信した成果物を一意に識別するための成果物ＩＤを生成する。次のステップＳ４では、成果物管理部１１が、受信した成果物を成果物記憶部１６に記憶する。次のステップＳ５では、成果物管理部１１が、生成した成果物ＩＤと、受信した前成果物ＩＤと、成果物のパスと、受信したユーザＩＤと、現在の日時を関連付けて成果物管理ＤＢ１５の成果物管理テーブルに登録する。また、成果物管理部１１は、受信した前成果物ＩＤの後成果物ＩＤに生成した成果物ＩＤを追加する。具体的には、例えば、図４の成果物管理テーブルに示す成果物Ａ００９を登録する場合には、成果物管理部１１は、成果物管理テーブルにレコード｛Ａ００９，Ａ００７，ｎｕｌｌ，￥￥ｐｒｏｊｅｃｔ￥００９０１．ｄｏｃ，ＴＡ０７ＫＡ，２００８／５／２ １６：３０｝を挿入する。また、成果物管理部１１は、成果物Ａ００９の前成果物である成果物Ａ００７の後成果物ＩＤに「Ａ００９」を追加する。これにより、成果物が成果物管理サーバ１に登録される。
【００２２】
図８は、本実施形態における成果物管理サーバ１の成果物変更処理の流れの一例を示すフローチャートである。
この図に示す処理は、利用者端末２から成果物とともに成果物更新要求を受信するとスタートする。成果物更新要求は、成果物ＩＤを含む成果物の更新要求である。なお、成果物の変更は、利用者端末２の文書編集部２１により行われる。このとき、利用者端末２は、成果物の変更を行うために成果物の一覧取得要求を成果物管理サーバ１に送信する。成果物管理サーバ１は、成果物管理部１１において成果物管理ＤＢ１５を参照して成果物ＩＤの一覧を生成し、生成した一覧を利用者端末２に送信する。利用者端末２は、受信した一覧から成果物を選択し、成果物管理サーバ１に選択した結果を送信する。成果物管理サーバ１の成果物管理部１１は、作業者ＤＢ１４を参照して、作業者が選択された成果物の更新を行う正しい権限を持つか否かを判定する。正しい権限を持つか否かは、作業者が成果物の作成者と同じグループの場合に正しい権限を持つと判定する。正しい権限を持つと判定された場合、成果物管理部１１は、成果物記憶部１６から成果物を取得して利用者端末２に送信する。これにより、利用者端末２は、成果物の変更が可能となる。
【００２３】
まず、ステップＳ１０１では、成果物管理部１１が、受信した成果物を成果物記憶部１６に記憶する。次のステップＳ１０２では、成果物管理部１１が、成果物管理ＤＢ１５の成果物管理テーブルを更新する。具体的には、成果物管理部１１は、受信した成果物に対応するパスをステップＳ１０１で記憶した成果物のパスに書き替える。また、成果物管理部１１は、受信した成果物に対応する更新日時を現在の時刻に書き替える。
次のステップＳ１０３では、成果物更新監視部１２が、受信した成果物更新要求に変更識別ＩＤが含まれるか否かを判定する。変更識別ＩＤが含まれる場合には、次のステップＳ１０９に進む。一方、変更識別ＩＤが含まれない場合には、ステップＳ１０４に進む。
ステップＳ１０４では、成果物更新監視部１２が、変更識別ＩＤを生成する。次のステップＳ１０５では、成果物更新監視部１２が、生成した変更識別ＩＤと受信した成果物を対応付けて履歴テーブルに登録する。
【００２４】
次に、ステップＳ１０７では、成果物更新監視部１２が、確認順序テーブルを生成する。確認順序テーブルの生成処理の詳細については後述する。次のステップＳ１０８では、成果物変更通知部１３が利用者端末２に確認依頼通知を送信して処理を終了する。具体的には、成果物変更通知部１３は、確認順序テーブルの先頭の成果物ＩＤを取得し、成果物管理テーブルを参照して当該成果物の作成者を特定する。そして、成果物変更通知部１３は、特定した作成者の利用者端末２に、取得した成果物ＩＤ、変更された成果物の成果物ＩＤ及び変更識別ＩＤを含む確認依頼通知を送信する。
【００２５】
一方、ステップＳ１０９では、成果物更新監視部１２が、受信した変更識別ＩＤと受信した成果物を対応付けて履歴テーブルに登録する。次のステップＳ１１０では、確認順序テーブルのマージ処理を行う。確認順序テーブルのマージ処理の詳細については後述する。次のステップＳ１１１では、確認順序テーブルの確認処理を行う。確認順序テーブルの確認処理の詳細については後述する。
【００２６】
図９は、本実施形態における確認順序テーブルの生成処理を説明するための概略図である。この図に示す例は、成果物Ａ００４が変更された場合の確認順序テーブルである。
まず、成果物更新監視部１２は、前方向の抽出を行う。具体的には、成果物更新監視部１２は、まず、更新された成果物Ａ００４に対して前成果物を全て抽出する。成果物Ａ００４の前成果物は成果物Ａ００２及びＡ００３である。成果物更新監視部１２は、抽出した前成果物Ａ００２及びＡ００３のレコードを順に確認順序テーブルに格納する。このとき、成果物更新監視部１２は、リンク元成果物ＩＤを成果物Ａ００４とする。
次に、成果物更新監視部１２は、抽出した前成果物Ａ００２及びＡ００３の前成果物をそれぞれ抽出する。成果物Ａ００２の前成果物は成果物Ａ００１である。成果物更新監視部１２は、成果物Ａ００１のレコードを成果物Ａ００２の直後に挿入する。このとき、成果物更新監視部１２は、リンク元成果物ＩＤを成果物Ａ００２とする。一方、成果物Ａ００３の前成果物は成果物Ａ００１である。成果物更新監視部１２は、成果物Ａ００１のレコードを成果物Ａ００３のレコードの直後に挿入する。このとき、成果物更新監視部１２は、リンク元成果物ＩＤを成果物Ａ００３とする。成果物更新監視部１２は、この処理を前成果物がなくなるまで繰り返す。
【００２７】
成果物Ａ００１には前成果物がないので、次に成果物更新監視部１２は、後方向の抽出を行う。具体的には、成果物更新監視部１２は、まず、成果物Ａ００４の後成果物を全て抽出する。成果物Ａ００４の後成果物は、成果物Ａ００６及びＡ００７である。成果物更新監視部１２は、抽出した成果物Ａ００６及びＡ００７のレコードを順に確認順序テーブルに格納する。このとき、成果物更新監視部１２は、リンク元成果物ＩＤを成果物Ａ００４とする。
次に、成果物更新監視部１２は、抽出した成果物Ａ００６及びＡ００７の後成果物をそれぞれ抽出する。成果物Ａ００６の後成果物はない。成果物Ａ００７の後成果物は成果物Ａ００８及びＡ００９である。成果物更新監視部１２は、成果物Ａ００８及びＡ００９のレコードを成果物Ａ００７の直後に挿入する。このとき、成果物更新監視部１２は、リンク元成果物ＩＤを成果物Ａ００７とする。成果物更新監視部１２は、この処理を後成果物がなくなるまで繰り返す。これにより、図９（ａ）に示すテーブルが生成される。
【００２８】
成果物更新監視部１２は、後方向の抽出が終了すると、成果物ＩＤが同一のレコードが格納されていないか否かを判定する。図９（ａ）に示す例では、成果物Ａ００１が重複している。この場合、成果物更新監視部１２は、先に格納されているレコードを削除するとともに、削除したレコードのリンク元成果物ＩＤを後に格納されたレコードのリンク元成果物ＩＤに追加する。これにより図９（ｂ）に示す確認順序テーブルが生成される。
【００２９】
図１０は、本実施形態における成果物管理サーバ１の確認順序テーブル確認処理の流れの一例を示すフローチャートである。
この図に示す処理は、上述したステップＳ１１１に対応する処理である。また、この図に示す処理は、利用者端末２から確認通知を受信した場合にも行われる。確認通知は、成果物ＩＤを含む、作業者が変更を確認したことを示す通知である。確認通知及び変更識別ＩＤを含む成果物更新要求は、確認依頼の応答である。
まず、ステップＳ２０１では、成果物更新監視部１２が、受信した成果物ＩＤに対応する確認順序テーブルの確認フラグを「ＯＮ」にする。次のステップＳ２０１では、成果物更新監視部１２が、全ての成果物の確認処理が完了したか否かを判定する。具体的には、確認順序テーブルの全ての成果物の確認フラグが「ＯＮ」である場合に、確認処理が全て完了したと判定する。確認処理が全て完了した場合には、処理を終了する。一方、完了していない場合には、ステップＳ２０３に進む。ステップＳ２０３では、成果物変更通知部１３が、確認順序テーブルから次に更新すべき成果物の成果物ＩＤを取得する。具体的には、成果物変更通知部１３は、確認処理が完了していない成果物であって、確認順序テーブルの最も前方に格納されている成果物を次に更新すべき成果物とする。次のステップＳ２０４では、成果物変更通知部１３が、成果物管理テーブルを参照して次に更新すべき成果物の作成者を特定する。そして、成果物変更通知部１３は、特定した作成者の利用者端末２に、更新すべき成果物の成果物ＩＤ、変更された成果物の成果物ＩＤ及び変更識別ＩＤを含む確認依頼通知を送信する。
【００３０】
図１１は、本実施形態における、成果物管理サーバ１の確認順序テーブルマージ処理を説明するための概略図である。
この図に示す処理は、上述したステップＳ１１０に対応する処理である。図１１に示す例では、成果物Ａ００４の変更に対する確認処理が完了していない状態で、成果物Ａ００３が変更された場合の処理を示す。図１１（ａ）は、既に生成された確認順序テーブルである。図１１（ｂ）は、成果物Ａ００３の変更により図９に示す処理で新たに生成された確認順序テーブルである。図１１（ｃ）は、図１１（ａ）及び図１１（ｂ）をマージした結果である。
成果物更新監視部１２は、図１１（ａ）のレコードＡ００３の直後に図１１（ｂ）の確認順序テーブルを挿入する。このとき、成果物更新監視部１２は、図１１（ｂ）のレコードＡ００３を削除する。次に、成果物更新監視部１２は、新たに挿入されたレコードの内、図１１（ａ）で確認フラグが既に「ＯＮ」になっているレコードを削除する。図１１（ｃ）に示す例では、Ａ００４及びＡ００１のレコードの確認フラグが既に「ＯＮ」になっているので、新たに挿入されたレコードが削除される。次に、成果物更新監視部１２は、重複しているレコードがある場合には、前のレコードを削除するとともに、削除したレコードのリンク元成果物ＩＤを後のレコードのリンク元成果物ＩＤに追加する。このようにして、図１１（ｃ）に示す確認順序テーブルが更新される。
【００３１】
次に、確認処理が予め設定された時間内に完了しない場合の処理について説明する。
成果物変更通知部１３は、まず、確認順序テーブルを参照して、確認依頼通知の送信時間から予め設定された時間が経過しても確認フラグが「ＯＮ」になっていない成果物ＩＤを取得する。次に、成果物変更通知部１３は、成果物管理テーブルを参照して当該成果物の作成者を特定する。そして、成果物変更通知部１３は、作業者テーブルを参照して特定した作成者と同一のグループに所属する作業者を抽出する。最後に、成果物変更通知部１３は、抽出した作業者全員の利用者端末２に再度確認依頼通知を送信する。これにより、作業者に再度確認を促すことができる。なお、本実施形態では、作成者と同一のグループに所属する作業者全員に再度確認依頼通知を送信したが、作業者テーブルに権限情報を記憶して、特定した作成者と同一のグループに所属し、より上位の権限を持つ作業者に確認依頼通知を送信してもよい。
【００３２】
次に成果物更新のキャンセル処理について説明する。
成果物変更通知部１３からの確認依頼通知により作業者が成果物の確認を行った際、なんらかの理由により一連の更新処理を認められない場合には、当該更新をキャンセルすることができる。この場合、作業者の操作により利用者端末２が成果物管理サーバ１に変更識別ＩＤ及び成果物ＩＤを含むキャンセル要求を送信する。成果物管理サーバ１の成果物管理部１１は、キャンセル要求を受信すると、履歴テーブルを参照して、受信した変更識別ＩＤ及び成果物ＩＤをキーにそのパスを取得する。そして、成果物管理部１１は、成果物管理テーブルの当該成果物ＩＤに対応するパスを取得したパスに置き換えるロールバック処理を行う。これにより、更新のキャンセルを行うことができる。
【００３３】
このように、本実施形態によれば、成果物更新監視部１２は、成果物の変更が生じると、その変更に影響する成果物を更新すべき順に抽出して確認順序テーブルを生成する。また、成果物変更通知部１３は、確認順序テーブルに基づいて利用者端末２に確認依頼通知を送信する。作業者は、通知された順に成果物を更新するため、システム開発における成果物の変更が生じた場合に、手戻り作業における成果物の不整合を軽減することができる。これにより、成果物の不整合による再度の手戻り作業を抑制することができる。
また、予め設定された時間内に確認処理が完了しない場合には、再度確認依頼通知を行うため、作業者に再度確認を促すことができ、手戻り作業が滞ることを防ぐことができる。
【００３４】
［第２の実施形態］
次に、この発明の第２の実施形態による成果物管理サーバ１について説明する。
第１の実施形態では、分岐が多い成果物の場合、リンク元成果物が全て確認されないと当該成果物の更新又は確認が行えない。そのため、分岐が多い場合には、全ての成果物の更新までに時間を要することがある。そこで、本実施形態の成果物管理サーバ１では、各成果物間の関連の重要度を考慮して確認順序テーブルを生成する。
【００３５】
まず、成果物の登録処理について説明する。
成果物管理サーバ１の成果物管理部１１は、新規成果物登録要求を受信すると、利用者端末２に、前成果物ＩＤ及びユーザＩＤとともに受信した成果物と前成果物間の関連の重要度を要求する。そして、成果物管理部１１は、利用者端末２から受信した関連の重要度を成果物管理ＤＢ１５に記憶する。
図１２は、本実施形態における成果物管理ＤＢ１５に記憶される重要度テーブルのデータ構造及びデータ例を示す概略図である。
重要度テーブルは、前工程の成果物と後工程の成果物の関係の重要度を記憶する。図示するように、重要度テーブルは、行と列からなる２次元の表形式のデータであり、成果物ＩＤと、前成果物ＩＤと、重要度と、の各項目の列を有している。この重要度テーブルの主キーは成果物ＩＤと前成果物ＩＤである。重要度は、成果物と前成果物間の関連の重要度を示す。重要度は、１からＮまでの正の整数で表わされ、大きいほど重要度が高く、小さいほど重要度が低くなる。Ｎは２以上の整数である。
【００３６】
次に、確認順序テーブルの生成処理について説明する。
成果物更新監視部１２は、前方向の抽出を行う際に、重要度の高い前成果物でつながるルートから順に確認順序テーブルに格納する。同様に、成果物更新監視部１２は、後方向の抽出を行う際に、重要度の高い後成果物で繋がるルートから順に確認順序テーブルに格納する。これにより、変更した成果物とより関連性の高い成果物から確認処理を行うことができる。
他の構成は第１の実施形態と同様なので説明を省略する。
【００３７】
このように、本実施形態によれば、各成果物間の関連の重要度に基づいて確認順序テーブルを生成する。これにより、変更した成果物とより関連性の高い成果物から確認処理を行うことができ、より短時間で変更への対応をすることができる。
【００３８】
また、図１に示す成果物管理サーバ１の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、成果物管理処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【００３９】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【００４０】
以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
【００４１】
例えば、本実施形態では、確認順序テーブルに抽出された全ての成果物に対して確認依頼通知を送信することとしたが、確認した作業者が、軽微な修正であると判断した場合には、確認不要として確認処理を完了するように構成してもよい。この場合、作業者の操作により利用者端末２は、成果物管理サーバ１に確認不要と判定した成果物ＩＤを含む確認不要通知を送信する。成果物管理サーバ１の成果物更新監視部１２は、確認不要通知を受信すると、確認順序テーブルの受信した成果物ＩＤに対応する確認フラグを「ＯＮ」にするとともに、当該成果物ＩＤをリンク元成果物ＩＤに持つ成果物ＩＤに対応する確認フラグを「ＯＮ」にする。また、成果物更新監視部１２は、確認フラグを「ＯＮ」にした成果物ＩＤをリンク元成果物ＩＤに持つ成果物ＩＤに対しても同様の処理を行う。成果物更新監視部１２は、確認フラグを「ＯＮ」にした成果物ＩＤをリンク元成果物ＩＤに持つ成果物ＩＤがなくなるまでこの処理を繰り返す。なお、複数のリンク元成果物ＩＤを持つ成果物には、この処理を行わない。
【００４２】
また、本実施形態では、１つのファイル毎に確認を行うこととしたが、１つのファイルに複数の項目を含め、各項目に成果物ＩＤを付与してもよい。この場合、影響範囲が少数に区切られる為、確認作業が容易になる。
【図面の簡単な説明】
【００４３】
【図１】第１の実施形態による成果物管理システムの構成を示すブロック図である。
【図２】本実施形態における成果物の関連の一例を示す概略図である。
【図３】本実施形態における作業者ＤＢに記憶される作業者テーブルのデータ構造及びデータ例を示す概略図である。
【図４】本実施形態における成果物管理ＤＢに記憶される成果物管理テーブルのデータ構造及びデータ例を示す概略図である。
【図５】本実施形態における履歴ＤＢに記憶される履歴テーブルのデータ構造及びデータ例を示す概略図である。
【図６】本実施形態における確認順序ＤＢに記憶される確認順序テーブルのデータ構造及びデータ例を示す概略図である。
【図７】本実施形態における成果物管理サーバの成果物登録処理の流れを示すフローチャートである。
【図８】本実施形態における成果物管理サーバの成果物変更処理の流れの一例を示すフローチャートである。
【図９】本実施形態における確認順序テーブルの生成処理を説明するための概略図である。
【図１０】本実施形態における成果物管理サーバの確認順序テーブル確認処理の流れの一例を示すフローチャートである。
【図１１】本実施形態における、成果物管理サーバの確認順序テーブルマージ処理を説明するための概略図である。
【図１２】本実施形態における成果物管理ＤＢに記憶される重要度テーブルのデータ構造及びデータ例を示す概略図である。
【図１３】成果物の変更により発生する手戻り作業の一例を示した概略図である。
【符号の説明】
【００４４】
１…成果物管理サーバ ２…利用者端末 １１…成果物管理部 １２…成果物更新監視部 １３…成果物変更通知部 １４…作業者ＤＢ １５…成果物管理ＤＢ １６…成果物記憶部 １７…履歴ＤＢ １８…確認順序ＤＢ
【技術分野】
【０００１】
本発明は、成果物管理サーバ、成果物管理方法及びプログラムに関する。
【背景技術】
【０００２】
一般に、システム開発では、各工程における成果物（要件定義書、基本設計書、詳細設計書、関数定義など）は、前の工程の成果物に基づいて作成される。例えば、基本設計書は前の工程の成果物である要件定義書に基づいて作成される。
ところで、これらの成果物は、様々な要因から頻繁に変更が発生する。その場合に、この変更により影響がある成果物を修正する手戻り作業が生じる。例えば、ある成果物に変更が発生した場合には、工程を一つずつ戻り、当該成果物より前の工程で作成された成果物（以下、前成果物とする）に対して影響があれば、その前成果物を更新する必要がある。しかしながら、実際のシステム開発では各成果物が１対１に対応しているわけではなく、複数の文書間に関連が存在する。
特許文献１に記載された技術では、ある成果物の変更がどの成果物に影響が及ぶかを予め設定（リンク付け）しておき、実際に変更が生じた場合の影響範囲（影響する成果物）を特定している。
【０００３】
図１３は、成果物の変更により発生する手戻り作業の一例を示した概略図である。
この図に示す例では、要件定義書Ａに基づいて基本設計書Ｂが作成されている。また、基本設計書Ｂに基づいて詳細設計書Ｃ及び詳細設計書Ｄが作成されている。また、関数定義書Ｅは、詳細設計書Ｃ及び詳細設計書Ｄに基づいて作成されている。
ここで、関数定義書Ｅにおいて、採用ＯＳをＷｉｎｄｏｗｓ（登録商標）からＬｉｎｕｘに、使用言語をＪａｖａ（登録商標）からＣ言語に変更した場合について説明する。
この変更を受けて、詳細設計書Ｃでは採用ＯＳと使用言語を変更する必要がある。また、詳細設計書Ｄでは採用ＯＳと使用言語に加えて、採用ＤＢをＭｙＳＱＬからＤＢ２に変更する必要がある。これにより、基本設計書Ｂでは、詳細設計書Ｃと詳細設計書Ｄの変更の影響を受けて、採用ＯＳ、使用言語及び採用ＤＢを変更する必要がある。
基本設計書Ｂは、当該成果物より後の工程で作成された成果物（以下、後成果物とする）が複数存在する。そのため、基本設計書Ｂには複数の成果物（詳細設計書Ｃ及び詳細設計書Ｄ）の変更の影響が及ぶ。以降では、基本設計書Ｂのような後成果物が複数存在する成果物のことを分岐元成果物と呼ぶ。
上述した例では、詳細設計書Ｃと詳細設計書Ｄの変更が完了した後、基本設計書Ｂに対する変更が行われなければならない。もし、詳細設計書Ｃの変更だけが完了している状況で、基本設計書Ｂを変更してしまうと、詳細設計書Ｄの変更の影響を加味することができず、基本設計書Ｂにおける採用ＤＢの変更が抜けてしまう、という成果物の不整合が生じる。
【特許文献１】特開２００７−１８３３４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載された技術では、成果物の変更により発生する手戻り作業における成果物の変更順序については考慮していないため、上述したような成果物の不整合が生じる可能性がある、という問題がある。
本発明は上記の点に鑑みてなされたものであり、その目的は、システム開発における成果物の変更が生じた場合に、その変更により発生する手戻り作業における成果物の不整合を軽減することができる成果物管理サーバ、成果物管理方法及びプログラムを提供することにある。
【課題を解決するための手段】
【０００５】
本発明は上記の課題を解決するためになされたものであり、本発明の一態様は、工程毎に作成される成果物を管理する成果物管理サーバであって、各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部と、成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出する成果物変更監視部と、前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信する成果物変更通知部と、を備えることを特徴とする成果物管理サーバ
【０００６】
また、本発明の一態様は、上記の成果物管理サーバにおいて、前記成果物更新監視部は、さらに、変更有りと確認された成果物が、前記成果物変更通知部が送信した確認依頼に基づいて変更された成果物だった場合、前記成果物記憶部から新たに修正の確認をすべき成果物を抽出し、確認順序情報を更新することを特徴とする。
【０００７】
また、本発明の一態様は、上記の成果物管理サーバにおいて、前記成果物更新監視部は、変更が生じた成果物を基点として、前工程の成果物を順次遡って抽出した後に、後工程の成果物を工程に沿って順次抽出する事を特徴とする。
【０００８】
また、本発明の一態様は、上記の成果物管理サーバにおいて、前記成果物情報記憶部は、さらに、成果物と、当該成果物と前後関係にある成果物との関係の重要度を記憶し、前記成果物更新監視部は前記重要度に基づいて確認順序情報を抽出することを特徴とする。
【０００９】
また、本発明の一態様は、工程毎に作成される成果物を管理する成果物管理方法であって各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部を備える成果物管理サーバが、成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出するステップと、前記成果物管理サーバが、前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信するステップと、を有することを特徴とする成果物管理方法である。
【００１０】
工程毎に作成される成果物を管理するためのプログラムであって、各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部を備えるコンピュータに、成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出するステップと、前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信するステップと、を実行させるためのプログラムである。
【発明の効果】
【００１１】
本発明によれば、各工程で作成される成果物の工程間の前後関係を記憶し、成果物の変更が生じると、当該成果物の変更を修正すべき成果物を更新すべき順に抽出するので、作業者は抽出された順に従って成果物を更新することができる。これにより、システム開発における成果物の変更が生じた場合に、その変更により発生する手戻り作業における成果物の不整合を軽減することができる。また、成果物の不整合による再度の手戻り作業を抑制することができる。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照しながら本発明の実施形態について詳しく説明する。
［第１の実施形態］
図１は、本発明の実施形態による成果物管理システムの構成を示すブロック図である。成果物管理システムは、成果物管理サーバ１と複数の利用者端末２から構成される。利用者端末２は成果物の作成又は更新を行う作業者が利用する端末である。利用者端末２は、成果物を編集する文書編集部２１を含んで構成される。
成果物管理サーバ１は、成果物管理部１１と、成果物更新監視部１２と、成果物変更通知部１３と、作業者ＤＢ（データベース）１４と、成果物管理ＤＢ（データベース）１５（成果物管理情報記憶部）と、成果物記憶部１６と、履歴ＤＢ（データベース）１７と、確認順序ＤＢ（データベース）１８と、を含んで構成される。
【００１３】
成果物管理部１１は、システム開発における各工程で生成された成果物を管理する。本実施形態では、成果物は、要件定義書、基本設計書、詳細設計書及び関数定義書などの各工程において生成されるドキュメントである。成果物管理部１１は、利用者端末２から成果物とともに新規成果物登録要求を受信すると、受信した成果物を成果物記憶部１６に記憶する。このとき、成果物管理部１１は、成果物を一意に識別する成果物ＩＤを生成し、記憶した成果物と対応付けて成果物管理ＤＢ１５に記憶する。また、成果物管理部１１は、利用者端末２から成果物とともに成果物更新要求を受信すると、受信した成果物を成果物記憶部１６に記憶する。このとき、成果物管理部１１は、成果物管理ＤＢ１５の成果物更新要求に含まれる成果物ＩＤに対応する成果物を新たに記憶した成果物に置き換える。
【００１４】
成果物更新監視部１２は、成果物の更新状況を管理する。成果物更新監視部１２は、成果物の変更が生じると、前記成果物の変更に影響する成果物を成果物間の関連に基づいて更新すべき順に抽出する。また、成果物更新監視部１２は、抽出した成果物が作業者の確認済みか否かを示す確認順序テーブル（確認順序情報）を生成して確認順序ＤＢ１８に記憶する。成果物変更通知部１３は、確認順序ＤＢ１８が更新されると、確認順序テーブルに基づいて利用者端末２に成果物変更通知を送信する。
【００１５】
図２は、本実施形態における成果物の関連の一例を示す概略図である。
この図に示す成果物Ａ００１〜Ａ００９は成果物記憶部１６に記憶されている。この図に示す例では、成果物Ａ００１の後成果物は成果物Ａ００２及び成果物Ａ００３である。成果物Ａ００２の前成果物は成果物Ａ００１であり、後成果物は成果物Ａ００４である。成果物Ａ００３の前成果物は成果物Ａ００１であり、後成果物は成果物Ａ００４及び成果物Ａ００５である。成果物Ａ００４の前成果物は成果物Ａ００２及び成果物Ａ００３であり、後成果物は成果物Ａ００６及び成果物Ａ００７である。成果物Ａ００５の前成果物は成果物Ａ００３であり、後成果物はない。成果物Ａ００６の前成果物は成果物Ａ００４であり、後成果物はない。成果物Ａ００７の前成果物は成果物Ａ００４であり、後成果物は成果物Ａ００８及び成果物Ａ００９である。成果物Ａ００８の前成果物は成果物Ａ００７であり、後成果物はない。成果物Ａ００９の前成果物は成果物Ａ００７であり、後成果物はない。
【００１６】
図３は、本実施形態における作業者ＤＢ１４に記憶される作業者テーブルのデータ構造及びデータ例を示す概略図である。
図示するように、作業者テーブルは、行と列からなる２次元の表形式のデータであり、ユーザＩＤと、メールアドレスと、所属グループＩＤと、の各項目の列を有している。この作業者テーブルの主キーは、ユーザＩＤである。作業者テーブルの各行は作業者毎に存在する。ユーザＩＤは、作業者を一意に識別するための識別番号である。メールアドレスは、作業者のメールアドレスである。所属グループＩＤは、作業者が所属するグループの識別番号である。
【００１７】
図４は、本実施形態における成果物管理ＤＢ１５に記憶される成果物管理テーブルのデータ構造及びデータ例を示す概略図である。
成果物管理テーブルは、システム開発における各成果物が生成される工程の前後関係を記憶する。図示するように、成果物管理テーブルは、行と列からなる２次元の表形式のデータであり、成果物ＩＤと、前成果物ＩＤと、後成果物ＩＤと、パスと、作成者と、変更日時と、の各項目の列を有している。この成果物管理テーブルの主キーは成果物ＩＤである。成果物管理テーブルの各行は成果物毎に存在する。成果物ＩＤは、成果物を一意に識別するための識別番号である。前成果物ＩＤは、前成果物の成果物ＩＤである。後成果物ＩＤは、後成果物の成果物ＩＤである。パスは、成果物が格納されているアドレスである。作成者は、成果物の作成者のユーザＩＤである。変更日時は、成果物を更新した日時である。なお、前成果物ＩＤ及び後成果物ＩＤの欄において、「ｎｕｌｌ」は、該当する成果物が存在しないことを表す。
【００１８】
図５は、本実施形態における履歴ＤＢ１７に記憶される履歴テーブルのデータ構造及びデータ例を示す概略図である。
履歴テーブルは、成果物の更新履歴を記録するテーブルである。図示するように、履歴テーブルは、行と列からなる２次元の表形式のデータであり、変更識別ＩＤと、成果物ＩＤと、パスと、変更日時と、の各項目の列を有している。変更識別ＩＤは、更新内容を一意に識別するための識別番号である。成果物ＩＤは、更新された成果物の成果物ＩＤである。パスは、更新された成果物を記憶しているアドレスである。変更日時は、成果物が更新された日時である。
【００１９】
図６は、本実施形態における確認順序ＤＢ１８に記憶される確認順序テーブルのデータ構造及びデータ例を示す概略図である。
確認順序テーブルは、成果物が変更されると成果物更新監視部１２により生成されるテーブルである。図示するように、確認順序テーブルは、行と列からなる２次元の表形式のデータであり、成果物ＩＤと、リンク元成果物ＩＤと、向きと、確認済みフラグと、の各項目の列を有している。この確認順序テーブルの主キーは成果物ＩＤである。確認順序テーブルの各行は成果物毎に存在する。リンク元成果物ＩＤは、変更された成果物から当該成果物へ繋がるリンクにおける直前の成果物の成果物ＩＤである。向きは、当該成果物がリンク元成果物に対して前成果物であるか後成果物であるかを示す。「ｐｒｅ」は、当該成果物がリンク元成果物の前成果物であることを表す。「ｐｏｓｔ」は、当該成果物がリンク元成果物の後成果物であることを表す。確認フラグは、当該成果物を作業者が確認済みであるか否かを示すフラグである。確認フラグが「ＯＮ」になると作業者が確認したことを表す。なお、図では、確認フラグが「ＯＮ」であることを「○」で表す。
【００２０】
図７は、本実施形態における成果物管理サーバ１の成果物登録処理の流れを示すフローチャートである。
利用者端末２は、作業者によって作成された成果物を新規成果物登録要求とともにネットワークを介して成果物管理サーバ１に送信する。図７に示す処理は、成果物管理サーバ１が成果物とともに新規成果物登録要求を受信するとスタートする。新規成果物登録要求は、新たに作成した成果物の登録要求である。
まず、ステップＳ１では、成果物管理部１１が、利用者端末２に受信した成果物の前成果物ＩＤ及び作業者のユーザＩＤを要求する。具体的には、成果物管理部１１は、利用者端末２の画面に前成果物ＩＤ及びユーザＩＤの入力画面を表示する。このとき、成果物管理部１１は、成果物管理ＤＢ１５の成果物管理テーブルから全ての成果物ＩＤを読み出して、その一覧を利用者端末２の画面に表示してもよい。これにより、利用者端末２は、一覧から前成果物ＩＤを選択することが可能になる。
次のステップＳ２では、成果物管理部１１が、利用者端末２から前成果物ＩＤ及びユーザＩＤを受信したか否かを判定する。前成果物ＩＤ及びユーザＩＤを受信すると、次のステップＳ３に進む。一方、受信していない場合には、ステップＳ２に戻る。
【００２１】
次のステップＳ３では、成果物管理部１１が、受信した成果物を一意に識別するための成果物ＩＤを生成する。次のステップＳ４では、成果物管理部１１が、受信した成果物を成果物記憶部１６に記憶する。次のステップＳ５では、成果物管理部１１が、生成した成果物ＩＤと、受信した前成果物ＩＤと、成果物のパスと、受信したユーザＩＤと、現在の日時を関連付けて成果物管理ＤＢ１５の成果物管理テーブルに登録する。また、成果物管理部１１は、受信した前成果物ＩＤの後成果物ＩＤに生成した成果物ＩＤを追加する。具体的には、例えば、図４の成果物管理テーブルに示す成果物Ａ００９を登録する場合には、成果物管理部１１は、成果物管理テーブルにレコード｛Ａ００９，Ａ００７，ｎｕｌｌ，￥￥ｐｒｏｊｅｃｔ￥００９０１．ｄｏｃ，ＴＡ０７ＫＡ，２００８／５／２ １６：３０｝を挿入する。また、成果物管理部１１は、成果物Ａ００９の前成果物である成果物Ａ００７の後成果物ＩＤに「Ａ００９」を追加する。これにより、成果物が成果物管理サーバ１に登録される。
【００２２】
図８は、本実施形態における成果物管理サーバ１の成果物変更処理の流れの一例を示すフローチャートである。
この図に示す処理は、利用者端末２から成果物とともに成果物更新要求を受信するとスタートする。成果物更新要求は、成果物ＩＤを含む成果物の更新要求である。なお、成果物の変更は、利用者端末２の文書編集部２１により行われる。このとき、利用者端末２は、成果物の変更を行うために成果物の一覧取得要求を成果物管理サーバ１に送信する。成果物管理サーバ１は、成果物管理部１１において成果物管理ＤＢ１５を参照して成果物ＩＤの一覧を生成し、生成した一覧を利用者端末２に送信する。利用者端末２は、受信した一覧から成果物を選択し、成果物管理サーバ１に選択した結果を送信する。成果物管理サーバ１の成果物管理部１１は、作業者ＤＢ１４を参照して、作業者が選択された成果物の更新を行う正しい権限を持つか否かを判定する。正しい権限を持つか否かは、作業者が成果物の作成者と同じグループの場合に正しい権限を持つと判定する。正しい権限を持つと判定された場合、成果物管理部１１は、成果物記憶部１６から成果物を取得して利用者端末２に送信する。これにより、利用者端末２は、成果物の変更が可能となる。
【００２３】
まず、ステップＳ１０１では、成果物管理部１１が、受信した成果物を成果物記憶部１６に記憶する。次のステップＳ１０２では、成果物管理部１１が、成果物管理ＤＢ１５の成果物管理テーブルを更新する。具体的には、成果物管理部１１は、受信した成果物に対応するパスをステップＳ１０１で記憶した成果物のパスに書き替える。また、成果物管理部１１は、受信した成果物に対応する更新日時を現在の時刻に書き替える。
次のステップＳ１０３では、成果物更新監視部１２が、受信した成果物更新要求に変更識別ＩＤが含まれるか否かを判定する。変更識別ＩＤが含まれる場合には、次のステップＳ１０９に進む。一方、変更識別ＩＤが含まれない場合には、ステップＳ１０４に進む。
ステップＳ１０４では、成果物更新監視部１２が、変更識別ＩＤを生成する。次のステップＳ１０５では、成果物更新監視部１２が、生成した変更識別ＩＤと受信した成果物を対応付けて履歴テーブルに登録する。
【００２４】
次に、ステップＳ１０７では、成果物更新監視部１２が、確認順序テーブルを生成する。確認順序テーブルの生成処理の詳細については後述する。次のステップＳ１０８では、成果物変更通知部１３が利用者端末２に確認依頼通知を送信して処理を終了する。具体的には、成果物変更通知部１３は、確認順序テーブルの先頭の成果物ＩＤを取得し、成果物管理テーブルを参照して当該成果物の作成者を特定する。そして、成果物変更通知部１３は、特定した作成者の利用者端末２に、取得した成果物ＩＤ、変更された成果物の成果物ＩＤ及び変更識別ＩＤを含む確認依頼通知を送信する。
【００２５】
一方、ステップＳ１０９では、成果物更新監視部１２が、受信した変更識別ＩＤと受信した成果物を対応付けて履歴テーブルに登録する。次のステップＳ１１０では、確認順序テーブルのマージ処理を行う。確認順序テーブルのマージ処理の詳細については後述する。次のステップＳ１１１では、確認順序テーブルの確認処理を行う。確認順序テーブルの確認処理の詳細については後述する。
【００２６】
図９は、本実施形態における確認順序テーブルの生成処理を説明するための概略図である。この図に示す例は、成果物Ａ００４が変更された場合の確認順序テーブルである。
まず、成果物更新監視部１２は、前方向の抽出を行う。具体的には、成果物更新監視部１２は、まず、更新された成果物Ａ００４に対して前成果物を全て抽出する。成果物Ａ００４の前成果物は成果物Ａ００２及びＡ００３である。成果物更新監視部１２は、抽出した前成果物Ａ００２及びＡ００３のレコードを順に確認順序テーブルに格納する。このとき、成果物更新監視部１２は、リンク元成果物ＩＤを成果物Ａ００４とする。
次に、成果物更新監視部１２は、抽出した前成果物Ａ００２及びＡ００３の前成果物をそれぞれ抽出する。成果物Ａ００２の前成果物は成果物Ａ００１である。成果物更新監視部１２は、成果物Ａ００１のレコードを成果物Ａ００２の直後に挿入する。このとき、成果物更新監視部１２は、リンク元成果物ＩＤを成果物Ａ００２とする。一方、成果物Ａ００３の前成果物は成果物Ａ００１である。成果物更新監視部１２は、成果物Ａ００１のレコードを成果物Ａ００３のレコードの直後に挿入する。このとき、成果物更新監視部１２は、リンク元成果物ＩＤを成果物Ａ００３とする。成果物更新監視部１２は、この処理を前成果物がなくなるまで繰り返す。
【００２７】
成果物Ａ００１には前成果物がないので、次に成果物更新監視部１２は、後方向の抽出を行う。具体的には、成果物更新監視部１２は、まず、成果物Ａ００４の後成果物を全て抽出する。成果物Ａ００４の後成果物は、成果物Ａ００６及びＡ００７である。成果物更新監視部１２は、抽出した成果物Ａ００６及びＡ００７のレコードを順に確認順序テーブルに格納する。このとき、成果物更新監視部１２は、リンク元成果物ＩＤを成果物Ａ００４とする。
次に、成果物更新監視部１２は、抽出した成果物Ａ００６及びＡ００７の後成果物をそれぞれ抽出する。成果物Ａ００６の後成果物はない。成果物Ａ００７の後成果物は成果物Ａ００８及びＡ００９である。成果物更新監視部１２は、成果物Ａ００８及びＡ００９のレコードを成果物Ａ００７の直後に挿入する。このとき、成果物更新監視部１２は、リンク元成果物ＩＤを成果物Ａ００７とする。成果物更新監視部１２は、この処理を後成果物がなくなるまで繰り返す。これにより、図９（ａ）に示すテーブルが生成される。
【００２８】
成果物更新監視部１２は、後方向の抽出が終了すると、成果物ＩＤが同一のレコードが格納されていないか否かを判定する。図９（ａ）に示す例では、成果物Ａ００１が重複している。この場合、成果物更新監視部１２は、先に格納されているレコードを削除するとともに、削除したレコードのリンク元成果物ＩＤを後に格納されたレコードのリンク元成果物ＩＤに追加する。これにより図９（ｂ）に示す確認順序テーブルが生成される。
【００２９】
図１０は、本実施形態における成果物管理サーバ１の確認順序テーブル確認処理の流れの一例を示すフローチャートである。
この図に示す処理は、上述したステップＳ１１１に対応する処理である。また、この図に示す処理は、利用者端末２から確認通知を受信した場合にも行われる。確認通知は、成果物ＩＤを含む、作業者が変更を確認したことを示す通知である。確認通知及び変更識別ＩＤを含む成果物更新要求は、確認依頼の応答である。
まず、ステップＳ２０１では、成果物更新監視部１２が、受信した成果物ＩＤに対応する確認順序テーブルの確認フラグを「ＯＮ」にする。次のステップＳ２０１では、成果物更新監視部１２が、全ての成果物の確認処理が完了したか否かを判定する。具体的には、確認順序テーブルの全ての成果物の確認フラグが「ＯＮ」である場合に、確認処理が全て完了したと判定する。確認処理が全て完了した場合には、処理を終了する。一方、完了していない場合には、ステップＳ２０３に進む。ステップＳ２０３では、成果物変更通知部１３が、確認順序テーブルから次に更新すべき成果物の成果物ＩＤを取得する。具体的には、成果物変更通知部１３は、確認処理が完了していない成果物であって、確認順序テーブルの最も前方に格納されている成果物を次に更新すべき成果物とする。次のステップＳ２０４では、成果物変更通知部１３が、成果物管理テーブルを参照して次に更新すべき成果物の作成者を特定する。そして、成果物変更通知部１３は、特定した作成者の利用者端末２に、更新すべき成果物の成果物ＩＤ、変更された成果物の成果物ＩＤ及び変更識別ＩＤを含む確認依頼通知を送信する。
【００３０】
図１１は、本実施形態における、成果物管理サーバ１の確認順序テーブルマージ処理を説明するための概略図である。
この図に示す処理は、上述したステップＳ１１０に対応する処理である。図１１に示す例では、成果物Ａ００４の変更に対する確認処理が完了していない状態で、成果物Ａ００３が変更された場合の処理を示す。図１１（ａ）は、既に生成された確認順序テーブルである。図１１（ｂ）は、成果物Ａ００３の変更により図９に示す処理で新たに生成された確認順序テーブルである。図１１（ｃ）は、図１１（ａ）及び図１１（ｂ）をマージした結果である。
成果物更新監視部１２は、図１１（ａ）のレコードＡ００３の直後に図１１（ｂ）の確認順序テーブルを挿入する。このとき、成果物更新監視部１２は、図１１（ｂ）のレコードＡ００３を削除する。次に、成果物更新監視部１２は、新たに挿入されたレコードの内、図１１（ａ）で確認フラグが既に「ＯＮ」になっているレコードを削除する。図１１（ｃ）に示す例では、Ａ００４及びＡ００１のレコードの確認フラグが既に「ＯＮ」になっているので、新たに挿入されたレコードが削除される。次に、成果物更新監視部１２は、重複しているレコードがある場合には、前のレコードを削除するとともに、削除したレコードのリンク元成果物ＩＤを後のレコードのリンク元成果物ＩＤに追加する。このようにして、図１１（ｃ）に示す確認順序テーブルが更新される。
【００３１】
次に、確認処理が予め設定された時間内に完了しない場合の処理について説明する。
成果物変更通知部１３は、まず、確認順序テーブルを参照して、確認依頼通知の送信時間から予め設定された時間が経過しても確認フラグが「ＯＮ」になっていない成果物ＩＤを取得する。次に、成果物変更通知部１３は、成果物管理テーブルを参照して当該成果物の作成者を特定する。そして、成果物変更通知部１３は、作業者テーブルを参照して特定した作成者と同一のグループに所属する作業者を抽出する。最後に、成果物変更通知部１３は、抽出した作業者全員の利用者端末２に再度確認依頼通知を送信する。これにより、作業者に再度確認を促すことができる。なお、本実施形態では、作成者と同一のグループに所属する作業者全員に再度確認依頼通知を送信したが、作業者テーブルに権限情報を記憶して、特定した作成者と同一のグループに所属し、より上位の権限を持つ作業者に確認依頼通知を送信してもよい。
【００３２】
次に成果物更新のキャンセル処理について説明する。
成果物変更通知部１３からの確認依頼通知により作業者が成果物の確認を行った際、なんらかの理由により一連の更新処理を認められない場合には、当該更新をキャンセルすることができる。この場合、作業者の操作により利用者端末２が成果物管理サーバ１に変更識別ＩＤ及び成果物ＩＤを含むキャンセル要求を送信する。成果物管理サーバ１の成果物管理部１１は、キャンセル要求を受信すると、履歴テーブルを参照して、受信した変更識別ＩＤ及び成果物ＩＤをキーにそのパスを取得する。そして、成果物管理部１１は、成果物管理テーブルの当該成果物ＩＤに対応するパスを取得したパスに置き換えるロールバック処理を行う。これにより、更新のキャンセルを行うことができる。
【００３３】
このように、本実施形態によれば、成果物更新監視部１２は、成果物の変更が生じると、その変更に影響する成果物を更新すべき順に抽出して確認順序テーブルを生成する。また、成果物変更通知部１３は、確認順序テーブルに基づいて利用者端末２に確認依頼通知を送信する。作業者は、通知された順に成果物を更新するため、システム開発における成果物の変更が生じた場合に、手戻り作業における成果物の不整合を軽減することができる。これにより、成果物の不整合による再度の手戻り作業を抑制することができる。
また、予め設定された時間内に確認処理が完了しない場合には、再度確認依頼通知を行うため、作業者に再度確認を促すことができ、手戻り作業が滞ることを防ぐことができる。
【００３４】
［第２の実施形態］
次に、この発明の第２の実施形態による成果物管理サーバ１について説明する。
第１の実施形態では、分岐が多い成果物の場合、リンク元成果物が全て確認されないと当該成果物の更新又は確認が行えない。そのため、分岐が多い場合には、全ての成果物の更新までに時間を要することがある。そこで、本実施形態の成果物管理サーバ１では、各成果物間の関連の重要度を考慮して確認順序テーブルを生成する。
【００３５】
まず、成果物の登録処理について説明する。
成果物管理サーバ１の成果物管理部１１は、新規成果物登録要求を受信すると、利用者端末２に、前成果物ＩＤ及びユーザＩＤとともに受信した成果物と前成果物間の関連の重要度を要求する。そして、成果物管理部１１は、利用者端末２から受信した関連の重要度を成果物管理ＤＢ１５に記憶する。
図１２は、本実施形態における成果物管理ＤＢ１５に記憶される重要度テーブルのデータ構造及びデータ例を示す概略図である。
重要度テーブルは、前工程の成果物と後工程の成果物の関係の重要度を記憶する。図示するように、重要度テーブルは、行と列からなる２次元の表形式のデータであり、成果物ＩＤと、前成果物ＩＤと、重要度と、の各項目の列を有している。この重要度テーブルの主キーは成果物ＩＤと前成果物ＩＤである。重要度は、成果物と前成果物間の関連の重要度を示す。重要度は、１からＮまでの正の整数で表わされ、大きいほど重要度が高く、小さいほど重要度が低くなる。Ｎは２以上の整数である。
【００３６】
次に、確認順序テーブルの生成処理について説明する。
成果物更新監視部１２は、前方向の抽出を行う際に、重要度の高い前成果物でつながるルートから順に確認順序テーブルに格納する。同様に、成果物更新監視部１２は、後方向の抽出を行う際に、重要度の高い後成果物で繋がるルートから順に確認順序テーブルに格納する。これにより、変更した成果物とより関連性の高い成果物から確認処理を行うことができる。
他の構成は第１の実施形態と同様なので説明を省略する。
【００３７】
このように、本実施形態によれば、各成果物間の関連の重要度に基づいて確認順序テーブルを生成する。これにより、変更した成果物とより関連性の高い成果物から確認処理を行うことができ、より短時間で変更への対応をすることができる。
【００３８】
また、図１に示す成果物管理サーバ１の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、成果物管理処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【００３９】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【００４０】
以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
【００４１】
例えば、本実施形態では、確認順序テーブルに抽出された全ての成果物に対して確認依頼通知を送信することとしたが、確認した作業者が、軽微な修正であると判断した場合には、確認不要として確認処理を完了するように構成してもよい。この場合、作業者の操作により利用者端末２は、成果物管理サーバ１に確認不要と判定した成果物ＩＤを含む確認不要通知を送信する。成果物管理サーバ１の成果物更新監視部１２は、確認不要通知を受信すると、確認順序テーブルの受信した成果物ＩＤに対応する確認フラグを「ＯＮ」にするとともに、当該成果物ＩＤをリンク元成果物ＩＤに持つ成果物ＩＤに対応する確認フラグを「ＯＮ」にする。また、成果物更新監視部１２は、確認フラグを「ＯＮ」にした成果物ＩＤをリンク元成果物ＩＤに持つ成果物ＩＤに対しても同様の処理を行う。成果物更新監視部１２は、確認フラグを「ＯＮ」にした成果物ＩＤをリンク元成果物ＩＤに持つ成果物ＩＤがなくなるまでこの処理を繰り返す。なお、複数のリンク元成果物ＩＤを持つ成果物には、この処理を行わない。
【００４２】
また、本実施形態では、１つのファイル毎に確認を行うこととしたが、１つのファイルに複数の項目を含め、各項目に成果物ＩＤを付与してもよい。この場合、影響範囲が少数に区切られる為、確認作業が容易になる。
【図面の簡単な説明】
【００４３】
【図１】第１の実施形態による成果物管理システムの構成を示すブロック図である。
【図２】本実施形態における成果物の関連の一例を示す概略図である。
【図３】本実施形態における作業者ＤＢに記憶される作業者テーブルのデータ構造及びデータ例を示す概略図である。
【図４】本実施形態における成果物管理ＤＢに記憶される成果物管理テーブルのデータ構造及びデータ例を示す概略図である。
【図５】本実施形態における履歴ＤＢに記憶される履歴テーブルのデータ構造及びデータ例を示す概略図である。
【図６】本実施形態における確認順序ＤＢに記憶される確認順序テーブルのデータ構造及びデータ例を示す概略図である。
【図７】本実施形態における成果物管理サーバの成果物登録処理の流れを示すフローチャートである。
【図８】本実施形態における成果物管理サーバの成果物変更処理の流れの一例を示すフローチャートである。
【図９】本実施形態における確認順序テーブルの生成処理を説明するための概略図である。
【図１０】本実施形態における成果物管理サーバの確認順序テーブル確認処理の流れの一例を示すフローチャートである。
【図１１】本実施形態における、成果物管理サーバの確認順序テーブルマージ処理を説明するための概略図である。
【図１２】本実施形態における成果物管理ＤＢに記憶される重要度テーブルのデータ構造及びデータ例を示す概略図である。
【図１３】成果物の変更により発生する手戻り作業の一例を示した概略図である。
【符号の説明】
【００４４】
１…成果物管理サーバ ２…利用者端末 １１…成果物管理部 １２…成果物更新監視部 １３…成果物変更通知部 １４…作業者ＤＢ １５…成果物管理ＤＢ １６…成果物記憶部 １７…履歴ＤＢ １８…確認順序ＤＢ
【特許請求の範囲】
【請求項１】
工程毎に作成される成果物を管理する成果物管理サーバであって、
各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部と、
成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出する成果物変更監視部と、
前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信する成果物変更通知部と、
を備えることを特徴とする成果物管理サーバ。
【請求項２】
前記成果物更新監視部は、さらに、変更有りと確認された成果物が、前記成果物変更
通知部が送信した確認依頼に基づいて変更された成果物だった場合、前記成果物記憶部から新たに修正の確認をすべき成果物を抽出し、確認順序情報を更新することを特徴とする請求項１に記載の成果物管理サーバ。
【請求項３】
前記成果物更新監視部は、変更が生じた成果物を基点として、前工程の成果物を順次遡って抽出した後に、後工程の成果物を工程に沿って順次抽出する事を特徴とする請求項１または２に記載の成果物管理サーバ。
【請求項４】
前記成果物情報記憶部は、さらに、成果物と、当該成果物と前後関係にある成果物との関係の重要度を記憶し、
前記成果物更新監視部は前記重要度に基づいて確認順序情報を抽出する
ことを特徴とする請求項１から３いずれか１の項に記載の成果物管理サーバ。
【請求項５】
工程毎に作成される成果物を管理する成果物管理方法であって
各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部を備える成果物管理サーバが、成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出するステップと、
前記成果物管理サーバが、前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信するステップと、
を有することを特徴とする成果物管理方法。
【請求項６】
工程毎に作成される成果物を管理するためのプログラムであって、
各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部を備えるコンピュータに、
成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出するステップと、
前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信するステップと、
を実行させるためのプログラム。
【請求項１】
工程毎に作成される成果物を管理する成果物管理サーバであって、
各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部と、
成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出する成果物変更監視部と、
前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信する成果物変更通知部と、
を備えることを特徴とする成果物管理サーバ。
【請求項２】
前記成果物更新監視部は、さらに、変更有りと確認された成果物が、前記成果物変更
通知部が送信した確認依頼に基づいて変更された成果物だった場合、前記成果物記憶部から新たに修正の確認をすべき成果物を抽出し、確認順序情報を更新することを特徴とする請求項１に記載の成果物管理サーバ。
【請求項３】
前記成果物更新監視部は、変更が生じた成果物を基点として、前工程の成果物を順次遡って抽出した後に、後工程の成果物を工程に沿って順次抽出する事を特徴とする請求項１または２に記載の成果物管理サーバ。
【請求項４】
前記成果物情報記憶部は、さらに、成果物と、当該成果物と前後関係にある成果物との関係の重要度を記憶し、
前記成果物更新監視部は前記重要度に基づいて確認順序情報を抽出する
ことを特徴とする請求項１から３いずれか１の項に記載の成果物管理サーバ。
【請求項５】
工程毎に作成される成果物を管理する成果物管理方法であって
各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部を備える成果物管理サーバが、成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出するステップと、
前記成果物管理サーバが、前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信するステップと、
を有することを特徴とする成果物管理方法。
【請求項６】
工程毎に作成される成果物を管理するためのプログラムであって、
各工程で作成される成果物の工程間の前後関係を記憶する成果物管理情報記憶部を備えるコンピュータに、
成果物の変更の有無を監視するとともに、当該成果物の変更に伴って、修正の確認を行うべき成果物を前記成果物情報記憶部の前後関係情報に基づいて、確認順序情報として修正を行うべき順に抽出するステップと、
前記確認順序情報に基づいて、利用者端末に修正の確認を行うべき成果物の確認依頼を順次送信するステップと、
を実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２００９−２９５０５０（Ｐ２００９−２９５０５０Ａ）
【公開日】平成２１年１２月１７日（２００９．１２．１７）
【国際特許分類】
【出願番号】特願２００８−１４９８９７（Ｐ２００８−１４９８９７）
【出願日】平成２０年６月６日（２００８．６．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００１０２７２８）株式会社エヌ・ティ・ティ・データ (438)
【Ｆターム（参考）】
【公開日】平成２１年１２月１７日（２００９．１２．１７）
【国際特許分類】
【出願日】平成２０年６月６日（２００８．６．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００１０２７２８）株式会社エヌ・ティ・ティ・データ (438)
【Ｆターム（参考）】
[ Back to top ]