(57)【特許請求の範囲】
【請求項１】
ドキュメントを作成するとともに、これを管理するためのドキュメント管理システムにおいて、
上記ドキュメントの構造や項目間の制約を定義してドキュメント定義情報を作成するための定義手段と、
上記定義手段により作成された上記ドキュメント定義情報に従って、ある文書体系に含まれる種々のドキュメント・インスタンスを作成するためのインスタンス作成手段と、
上記インスタンス作成手段により作成される上記ドキュメント・インスタンスに対してデータを入力するためのドキュメント入力手段と、
上記種々のドキュメント・インスタンス、及び上記ドキュメント入力手段でデータ入力された上記ドキュメントを格納するデータ記憶手段と、
上記ドキュメント入力手段でデータ入力された上記ドキュメントが、上記定義手段により作成された上記ドキュメント定義情報に基づく制約を満たすかどうかをチェックし、チェックの結果、制約を満たさないデータが入力されている上記ドキュメントは上記データ記憶手段に格納せずに、制約を満足するドキュメントのみを上記データ記憶手段に格納するように制御する制約管理手段とを備えることを特徴とするドキュメント管理システム。
【請求項２】
上記データ記憶手段には、上記文書体系に含まれない他のデータが上記種々のドキュメントとともに格納されており、上記ドキュメント入力手段で入力されるデータには、上記文書体系に含まれないデータに関する情報として、当該データが格納されている位置に関する参照情報を含むことを特徴とする請求項１に記載のドキュメント管理システム。
【請求項３】
上記定義手段で定義される上記ドキュメント定義情報には、上記ドキュメント内に入力される各項目のデータ型に関する情報、上記ドキュメント内を構成する項目の構造関係に関する情報、及び、上記ドキュメント間の構成関係に関する情報のうちの少なくとも何れか一つを含むことを特徴とする請求項１又は２に記載のドキュメント管理システム。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明はドキュメント管理システムに関し、特に、ソフトウェアの生産過程において種々のドキュメントを作成するとともに、これを管理するために用いて好適なものである。
【０００２】
【従来の技術】
従来、ソフトウェアの開発を行う際には、ソフトウェアの作成維持、管理などを容易にするために、そのソフトウェアの動作や処理内容、または使用方法などを記述した種々のドキュメントを作成することが行われている。例えば、要求仕様書、設計書、テスト仕様書、取扱い説明書などの文書がこのドキュメントに該当する。
【０００３】
ところで、実際のソフトウェア開発においては、通常、開発を行う組織固有の開発方法論に基づく文書体系が存在する。ソフトウェアの設計・製作者は、この文書体系に従って実際のドキュメントを作成するようにしている。このとき、ドキュメント作成者は、ソフトウェア開発用に設計されたドキュメント支援システム（文書ツール）を用いて必要なドキュメントを作成するのが一般的である。
【０００４】
【発明が解決しようとする課題】
しかしながら、従来は、文書体系に応じたドキュメントを作成することができるようにするために、上記文書ツールを文書体系ごとに開発する必要があった。このため、文書ツールの開発費用が非常に大きくなっていた。
【０００５】
このため、ドキュメントの作成にはワードプロセッサ等の汎用の文書ツールが使われる場合が多く、ドキュメントがその文書体系に基づいているかどうかを検査し、その品質を維持するための機能を持っていないため、作成されるドキュメントに品質上のばらつきを生じることがあった。
【０００６】
一方、ソフトウェアの開発を行う際には、プログラムやドキュメントなどを始めとして、多種多様の情報を扱うことが一般的である。そして、これらの情報の多くは、それぞれ独立しているものではなく、相互に関係を持っている。したがって、これらの情報を有機的に結合し、その情報管理を適切に行うことは極めて重要なことである。
【０００７】
ところが、従来のドキュメント支援システムでは、そのシステム内のドキュメントを管理することはできるが、ソフトウェア開発の他の成果物との制約を管理することは困難であった。例えば、ソフトウェアの開発を行うにあたって、プログラムと仕様書との関係を適切に管理することは非常に重要であるが、従来のドキュメント支援システムは、これを行うための機能を備えていなかった。
【０００８】
また、一連のソフトウェア開発において作成されるプログラムや各ドキュメントとの間で、その内容に矛盾を生じることがあり、ソフトウェア開発を行う際の障害となることがあった。
【０００９】
また、ドキュメント支援システムは、構成管理機能、プロセス管理機能、テスト支援機能、プログラミング機能等との関連が強いため、それらとの有効な連携を図る必要がある。しかしながら、実際には、種々のツールによって独自にドキュメントを作成する場合が多い。このように、各ツールで独自にドキュメントを作成していたのでは、開発効率の面から必ずしも有効的ではなかった。
【００１０】
本発明は、このような問題を解決するために成されたものであり、各組織ごとの開発方法論に依存しないドキュメント管理システムを作成し、ドキュメントの品質を一定レベル以上に維持することができるようにすることを目的とする。また、他の生成物との間で情報を有機的に結合することができるようにするとともに、他のツールに連動して動作することができるようにすることにより、ドキュメントの作成作業の効率を向上させることを目的としている。
【００１１】
【課題を解決するための手段】
本発明のドキュメント管理システムは、ドキュメントを作成するとともに、これを管理するためのドキュメント管理システムにおいて、上記ドキュメントの構造や項目間の制約を定義してドキュメント定義情報を作成するための定義手段と、上記定義手段により作成された上記ドキュメント定義情報に従って、ある文書体系に含まれる種々のドキュメント・インスタンスを作成するためのインスタンス作成手段と、上記インスタンス作成手段により作成される上記ドキュメント・インスタンスに対してデータを入力するためのドキュメント入力手段と、上記種々のドキュメント・インスタンス、及び上記ドキュメント入力手段でデータ入力された上記ドキュメントを格納するデータ記憶手段と、上記ドキュメント入力手段でデータ入力された上記ドキュメントが、上記定義手段により作成された上記ドキュメント定義情報に基づく制約を満たすかどうかをチェックし、チェックの結果、制約を満たさないデータが入力されている上記ドキュメントは上記データ記憶手段に格納せずに、制約を満足するドキュメントのみを上記データ記憶手段に格納するように制御する制約管理手段とを備えることを特徴とする。
【００１２】
本発明の他の特徴とするところは、上記データ記憶手段には、上記文書体系に含まれない他のデータが上記種々のドキュメントとともに格納されており、上記ドキュメント入力手段で入力されるデータには、上記文書体系に含まれないデータに関する情報として、当該データが格納されている位置に関する参照情報を含むことを特徴とする。
【００１３】
本発明の更に他の特徴とするところは、上記定義手段で定義される上記ドキュメント定義情報には、上記ドキュメント内に入力される各項目のデータ型に関する情報、上記ドキュメント内を構成する項目の構造関係に関する情報、及び、上記ドキュメント間の構成関係に関する情報のうちの少なくとも何れか一つを含むことを特徴とする。
【００１４】
【作用】
上記のように構成した本発明によれば、各組織ごとの特有の文書体系に従ったドキュメント定義情報を作成し、このドキュメント定義情報に従って必要なドキュメント・インスタンスを作成し、作成したドキュメント・インスタンスにデータ入力を行ってドキュメントを作成する。また、本発明においては、ドキュメントが上記ドキュメント定義情報に基づく制約を満たすかどうかをチェックし、そのチェックの結果、制約を満たさないデータが入力されているドキュメントはデータ記憶手段に格納せずに、制約を満足するドキュメントのみをデータ記憶手段に格納するように制御している。
【００１５】
また、本発明においては、ドキュメント入力手段で入力されるデータには、上記文書体系に含まれないデータに関する情報として、当該データが格納されている位置に関する参照情報を含むようにしている。
【００１７】
【実施例】
図１は、本発明の一実施例であるドキュメント管理システムの概略的な構成を示すブロック図である。以下、この図１に基づいて、本実施例によるドキュメント管理システムの構成および動作について説明する。
【００１８】
図１において、２０は本実施例のドキュメント管理システムであり、ドキュメント定義部１、ドキュメント定義情報記憶部２、ドキュメント記憶部３、他データ記憶部４、ドキュメント管理部５、インスタンス作成部６、ドキュメント入力・修正部７、制約管理部８、ドキュメント出力部９および検索部１０により構成されている。
【００１９】
上述のドキュメント定義部１は、１つの文書体系に含まれる各ドキュメントの構造やその間の制約あるいは関係を、文書管理システムと分離した形でユーザ独自の方法論に基づいて定義するためのものである。すなわち、ドキュメントの管理者は、このドキュメント定義部１を用いて、ドキュメント内あるいはドキュメント間の制約や関係を定義して、後述するようなドキュメント定義情報を作成する。
【００２０】
次いで、ドキュメント定義情報記憶部２は、上記ドキュメント定義部１によって作成されるドキュメント定義情報を記憶するためのものである。また、ドキュメント記憶部３は、後述するインスタンス作成部６やドキュメント入力・修正部７によって作成されるドキュメントを記憶するためのものである。
【００２１】
さらに、他データ記憶部４は、上記ドキュメント以外の種々のデータを記憶するためのものである。例えば、この他データ記憶部４には、用語辞書として用いられる用語データ、プログラムなどのデータが記憶されている。そして、以上の各記憶部２〜４に記憶されているデータは、１つのデータベースとして一元的に管理されている。
【００２２】
次いで、ドキュメント管理部５は、ドキュメントに関する一般的な管理を行うためのものである。例えば、ドキュメント管理部５は、ドキュメントの管理者または作成者からの指示に従って、ドキュメント記憶部３に既に保存されているドキュメントの削除、複写、移動をデータ管理部５ａにより行う。なお、ドキュメントが削除可能であるかどうか、あるいは新規作成可能であるかどうかは、ドキュメント定義情報記憶部２に与えられるプロジェクト型に基づいて判断する。
【００２３】
また、ドキュメント移入部５ｂにより、本ドキュメント管理システム２０と他のドキュメント管理システム３０との間でドキュメントの交換を行う。さらに、スクリプト制御部５ｃにより、プログラムツールやテストツールなどの外部ツール４０からの要求に従って、ドキュメント入力・修正部７、ドキュメント出力部９、検索部１０にスクリプト（通信メッセージ）を送ることにより、ドキュメントの作成、削除、入出力、表示、印刷、検索などを行うように制御する。
【００２４】
次いで、インスタンス作成部６は、ドキュメント定義情報記憶部２に格納されているドキュメント定義情報に従って、ドキュメント・インスタンスを作成するためのものである。このドキュメント・インスタンスについては後述する。また、ドキュメント入力・修正部７は、上記インスタンス作成部６により作成されたドキュメント・インスタンスに様々なデータを入力し、あるいはそのデータに修正を加えていくことにより、所望のドキュメントを作成するためのものである。
【００２５】
次いで、制約管理部８は、上記ドキュメント定義部１によって定義されたドキュメント内の各項目間の制約や各ドキュメント間の制約などをドキュメントが常に満足するように制約維持の制御を行うためのものである。また、ドキュメント出力部９は、ドキュメントやそのインスタンスなどをディスプレイ装置などに表示する表示部９ａと、印刷装置などによりドキュメントを印刷する印刷部９ｂとを有している。
【００２６】
上記表示部９ａは、ドキュメント定義部１により定義されているドキュメント間の構造や項目間の関係などを確認し、相互に関係付けられている種々のドキュメントの一覧を表示し、選択できるようになされている。
【００２７】
次いで、検索部１０は、ドキュメント記憶部３または他データ記憶部４に格納されているドキュメントやその他の種々のデータの中から、所定の検索条件を満たすデータを検索するためのものである。
【００２８】
次に、上記ドキュメント定義部１によりドキュメントの構造や項目間の制約などを定義する手順について説明する。このような定義は、具体的には、ドキュメントの構造定義や構成関係定義、項目のデータ型定義や項目間の制約定義などによって行う。
【００２９】
ここで、ドキュメントの構造とは、そのドキュメント内がどのような項目から構成されているかを表すものである。また、ドキュメントの構成関係とは、あるプロジェクトにおける１つの文書体系の中でどのようなドキュメントが必要となるかを表すものである。
【００３０】
また、項目のデータ型とは、その項目に入力されるべきデータがどのような種類のデータであるか、例えば文字列データであるか、あるいは画像データであるかといったことを表すものである。さらに、項目間の制約とは、例えば、ドキュメントＡ内のａという項目とドキュメントＢ内のｂという項目は互いに等しいものであるといったような、項目間の関係を表すものである。
【００３１】
上記のような情報の定義の手順を説明する前に、ドキュメント作成の流れを説明する。
例えば、あるプロジェクトＡというものについて、ある開発方法論に基づいてプログラムを作成し、同時に関連ドキュメントを作成する場合を考える。
【００３２】
図４は、プロジェクトＡというシステムがサブシステムとそのサブシステムを構成するタスクという概念とから構成され、その構成において、作成すべき関連ドキュメントが何であるかを示している。これは、所定の開発方法論の下では決められたものであり、システム開発において守らなければならないプロジェクトの型と言える。したがって、図４は、プロジェクトの型の定義画面であり、その開発方法論に従うものであれば、共通するものである。
【００３３】
図４では、ドキュメントとして、プロジェクトＡについては“メモ”と“プロジェクト仕様書”とが作成可能であり、これ以外は作成不可能であることを示している。同様に、サブシステムについては“サブシステム仕様書１”と“サブシステム仕様書２”という２つの仕様書が作成され、タスクについては“タスク仕様書１”と“タスク仕様書２”という２つの仕様書が作成されることを示している。また、プログラムとしては、サブシステムについて“実行ファイル”と“ソースファイル”とが作成されることを示している。
【００３４】
上述のように、図４はプロジェクトの型を定義するときに現れる画面である。ここで、矢印で示したものは、複数のものを作成できることを表している。すなわち、サブシステムはプロジェクトＡに対して複数作成することができ、タスクはサブシステムに対して複数作成することができること意味している。
【００３５】
また、この画面において、プロジェクト、サブシステム、タスク等の関係を表すときに、実線、破線等の線表現を変える等して、必ず定義されなければならない必須要素と、必ずしも定義しなくてもよい任意要素とを区別して表現することができる。そして、図１の制約管理部８で必須要素が作成されているか否かをチェックし、作成されていないドキュメント一覧の表示等を行うことができる。
【００３６】
各仕様書、メモ等の後に＜＞で示されているものは、各々のドキュメントあるいはプログラムの型を示すものである。例えば、プロジェクト仕様書の後に示されている＜ｄｏｃ１＞は、上記プロジェクト仕様書が型＜ｄｏｃ１＞で作成されることを示している。
【００３７】
例えば、図４の画面中の“サブシステム仕様書１”のところをマウスでクリックすると、図示しないポップアップメニューが現れる。そして、そのメニューの中から文書型の表示を選択すると、図５に示す画面が現れる。図５は、＜ＳＰＥＣ１＞型のドキュメント形式である一部の頁を示す。
【００３８】
図５において、Ｌ１で示す部分は、ドキュメントの印刷、表示のイメージを示す領域であり、Ｌ２で示す部分は、上記領域Ｌ１の関連情報を示す領域である。上記イメージを示す領域Ｌ１内において、ｆ1 で示すフィールドにはプロジェクト名が入力され、ｆ2 で示すフィールドにはサブシステム名が入力され、ｆ3 で示すフィールドには作成者名が入力される。ただし、既に定義されているときは、その定義内容が表示される。また、四角い枠で示したフィールドｆ4 の中にはサブシステムの概要を表すテキストが入力され、フィールドｆ5 の中にはサブシステムの目的を表すテキストが入力される。
【００３９】
また、上記関連情報を示す領域Ｌ２内において、ｆ6 およびｆ7 で示すフィールドにはサブシステムの概要および目的を表すテキストの入力文字数がそれぞれ表示される。また、ｆ8 およびｆ9 で示すフィールドにはそれらの概要および目的を表すテキストが更新された時刻がそれぞれ表示される。例えば、フィールドｆ4 中の文字数とフィールドｆ6 に表示される数は同じであり、これは制約条件の１つとして定義することが可能である。
【００４０】
このような各定義は、以下に示す各定義部１ａ〜１ｄを用いてドキュメントの管理者が行う。すなわち、ドキュメントの管理者は、まず、データ型定義部１ａを用いて、ドキュメント定義部１に予め備えられている型（例えば、string,integer,image,double,enum,boolean,date,dictionary,list,textなどの型）から新しい型を定義する。
【００４１】
この新しい型は、予め備えられている型のサブタイプとして設定されるものである。例えば、ドキュメント管理者は、string型のサブタイプとして、人名の記述のみを許可する人名型を定義する。また、enum型のサブタイプとして、大中小の何れかの記述のみを許可する頻度型を定義したり、 boolean型のサブタイプとして、○×の何れかの記述のみを許可する○×型を定義したりする。また、string型がマッチしなければならないパターンや int型の最大値、最小値などの定義を行う。
【００４２】
例えば、図５に示したフィールドｆ4 内のデータの型を定義する際には、図６（ａ）に示すような画面により、テキストと指定される。また、フィールドｆ6 内のデータについては、図６（ｂ）に示すような画面により、整数として定義される。さらに、図６（ｃ）に示すように、図６（ａ）で定義された文字については、文字数が５ずつのステップで、最小１００から最大４００までの範囲になければならないことが定義される。
【００４３】
このような制約条件もドキュメント定義情報として定義され、図１の制約管理部８において、条件を満足しない入力や修正を行うことができないようにすることができる。
【００４４】
次に、ドキュメントの管理者は、文書型定義部１ｂを用いて、上述のようにして定義したデータ型を組み合わせて、文書型の定義を行う。この文書型とは、そのドキュメント内にはどのような項目が含まれていて、それぞれの項目にはどのようなデータ型が設定されているか、あるいは同じ項目がそのドキュメント内には何個存在し得るかといったような構造関係を表すものである。
【００４５】
次に、ドキュメントの管理者は、プロジェクト型定義部１ｃを用いて、対象としているプロジェクトに必要なドキュメントの名称、文書型および階層構造の定義を行う。
【００４６】
ところで、１つの文書体系の中には、文書の更新理由やメモなどように、必ずしも他の文書との関係を定義することが必要でない文書が存在する。以下、このような文書を「オプショナルな文書」と呼ぶ。本実施例では、その文書がオプショナルな文書か、あるいはオプショナルでない文書かを、このプロジェクト型の定義の段階で定義しておく。
【００４７】
次に、ドキュメントの管理者は、項目間制約定義部１ｄを用いて、１つのドキュメント内、あるいは複数のドキュメント間における各項目間の関係や制約をその種類ごとに定義する。すなわち、ドキュメント管理者は、後述する項目操作部７ｃの起動条件、起動コマンド、入力先、出力先を定義することにより、上記起動条件が満たされたときの起動コマンドや入出力先を対象項目に与えるようにする。
【００４８】
なお、図５に示したフィールドｆ4 の内容は、他のドキュメントでも同じ内容が使われるのであれば、他のドキュメント、例えばプロジェクト仕様書やタスク仕様書中の記載が変更される。これは、他のドキュメントでなくてもよく、同じドキュメント内の他の頁であっても同様である。
【００４９】
図７は、異なるドキュメント間で、それぞれの中にある項目１と項目ｎとの関係を、例えば、等しい、どちらか一方のみが入力されている、ソートした結果、などの関係とすることができることを示している。
【００５０】
このようにして各定義部１ａ〜１ｄによって定義されたドキュメント定義情報は、ドキュメント定義情報記憶部２に格納される。そして、このドキュメント定義情報記憶部２に格納された構造定義情報は、インスタンス作成部６によってドキュメント・インスタンスを作成する際に参照される。
【００５１】
また、上記各定義部１ａ〜１ｄで定義されたドキュメント定義情報は、スキーマ変換部１ｅにより各ドキュメントごとのデータベーススキーマに変換される。このスキーマは、実際のドキュメントをドキュメント記憶部３にどのような形で保存しておくかを定めた情報である。
【００５２】
以上のようにして、ドキュメントの管理者は、ドキュメント定義部１を用いて、１つの文書体系で作成される種々のドキュメントの構造や、そのドキュメント間あるいは項目間の制約、関係などを定義することにより、ドキュメント定義情報を作成する。
【００５３】
このように、本実施例では、各組織ごとに特有の開発方法論をドキュメント定義情報として定義し、このドキュメント定義情報に従って実際にドキュメントを作成するようにしているため、開発方法論の種類にかかわりなく共通のドキュメント管理システムを使用することができる。したがって、文書体系ごとにドキュメント管理システムを用意しなくても済み、そのための開発費用を節約することができる。
【００５４】
以下、上記ドキュメント定義情報に従ってドキュメントを作成する際の手順について説明する。すなわち、ドキュメント作成者は、まず、インスタンス作成部６を用いて、ドキュメント定義情報記憶部２に格納されているドキュメント定義情報に基づいてドキュメント・インスタンスを作成する。
【００５５】
すなわち、図２に示すように、ドキュメント作成者５０は、まず、ドキュメント定義情報選択部６ａを用いて、プロジェクト名を指定して、実際に作成しようとするインスタンスのドキュメント定義情報をドキュメント定義情報記憶部２の中から選択する。
【００５６】
次に、データ入力部６ｂを用いて、上記ドキュメント定義情報選択部６ａで選択したドキュメント定義情報に対して、インスタンス生成時に指定しなければならない項目、あるいは入力しなければならない項目にデータ（例えば、作成者名やドキュメント名等）を入力する。
【００５７】
このようにしてドキュメント作成者５０が必要なデータを入力すると、その入力したデータに基づいて、ドキュメント・インスタンスがインスタンス生成部６ｃにより生成される。なお、この生成の際には、ドキュメント作成者５０が入力したデータの他に、システムにより自動的に決定されるデータも用いられる。
【００５８】
次いで、ドキュメント作成者５０は、インスタンス格納部６ｄを用いて、上記インスタンス生成部６ｃで生成されたドキュメント・インスタンスをドキュメント記憶部３に格納する。
【００５９】
なお、このようなドキュメント・インスタンスの作成の際には、構成関係の制約に基づき作成可能なインスタンスは全て作成される。すなわち、１つの文書体系の中で必ず存在しなければならないドキュメントのインスタンスは、この時点で全て作成される。
【００６０】
次に、ドキュメント作成者５０は、ドキュメント入力・修正部７を用いて、上記インスタンス作成部６によって作成したドキュメント・インスタンスに対して、実際に文章を入力したり、各種のデータを入力したりするとともに、その入力した内容を適宜修正して、所望のドキュメントを作成する。ドキュメント入力・修正部７は、図３に示すように構成されている。
【００６１】
すなわち、ドキュメント作成者５０は、まず、ドキュメント入力・修正部７を起動する。なお、後述するように、外部ツール４０からスクリプトを送ることによりドキュメント入力・修正部７を起動する場合には、ドキュメントの文書名、その他所定のパラメータ等を引数にして起動する。起動できない場合には、エラーコードが外部ツール４０に返される。
【００６２】
ドキュメント入力・修正部７を起動すると、現在修正可能なドキュメントの一覧および新規作成可能なドキュメントの一覧が表示される。ドキュメント作成者５０は、図３のドキュメント選択部７ａを用いて、上記一覧の中から、データの入力あるいは修正を行おうとするドキュメントを選択する。
【００６３】
このようにしてドキュメント作成者５０がドキュメントを選択すると、その入力画面が表示部７ｂに表示される。ドキュメント作成者５０は、その入力画面内にある各項目に対して情報を入力し、あるいはそのデータに修正を加えるために、上記入力画面中から所望の項目を選択する。そして、ドキュメント作成者５０は、こうして選択した項目に対して、その項目に対応して起動される項目操作部７ｃを用いてデータの入力や修正を行う。
【００６４】
なお、本実施例では、上述のように、表示部７ｂと表示部９ａとを別個に設けているが、同一のものを使用するようにしてもよいことは言うまでもない。
【００６５】
次に、以上のようなデータの入力あるいは修正を行うことによりドキュメントを作成し終えると、ドキュメント作成者５０は、ドキュメント格納部７ｄを用いて、作成したドキュメントをその項目ごとにドキュメント記憶部３に格納する。このとき、ドキュメント作成者５０は、ドキュメントの内容の変更を行った理由を入力する。この変更理由は他のドキュメント管理システム３０に送られる。
【００６６】
これにより、他のドキュメント管理システム３０においてドキュメントを作成している他のドキュメント作成者は、関連するドキュメントについて内容の変更があったことを知ることができ、その変更理由に応じて適当に対処することができるようになる。したがって、相互に関連するドキュメント間で、その内容に矛盾が生じることを少なくすることができる。
【００６７】
また、作成したドキュメントをドキュメント記憶部３に格納する際には、制約管理部８によって、ドキュメント定義情報記憶部２に格納されているドキュメント定義情報に基づく制約などのチェックが行われる。ここで、制約外のデータが入力されている場合には、そのデータが格納されないように制御される。
【００６８】
この場合、エラーメッセージを発生するなどして、不適切なデータがあることをドキュメント作成者に知らせるようにしてもよい。また、上記ドキュメント定義情報に従って修正することが可能な項目のデータについては、制約管理部８が自動的に修正を行うようにしてもよい。
【００６９】
このように、本実施例のドキュメント管理システムによれば、ドキュメントの内容に変更を加えたときには、その変更後の内容がドキュメント定義情報に基づく種々の制約に従っているかが確かめられ、制約を満足している場合にのみそのドキュメントの保存が許される。したがって、ドキュメントを常に高品質に保っておくことが可能となる。
【００７０】
また、従来のように、ドキュメント作成者が、作成したドキュメントを目で見ることによってその内容を検査する必要がなくなるので、ドキュメントの生産性を向上させることもできる。
【００７１】
また、本実施例のドキュメント管理システムにおいては、ドキュメント内の各項目に種々のデータを入力する場合に、そのデータを直接入力したり、所定の参照情報を入力したりすることができるようになされている。例えば、通常の文章を入力する場合には、前者のように、該当項目にその文章を直接入力する。
【００７２】
一方、ドキュメント内に絵を取り込んだり、用語辞書内の用語を引用したり、他のドキュメントの一部を引用したり、プログラムの一部を引用したりする場合には、後者のように、所定の参照情報を該当項目に入力する。すなわち、引用しようとするデータを全てドキュメント内に取り込むのではなく、そのデータが格納されている位置情報を上記参照情報として取り込むようにしている。
【００７３】
例えば、他のドキュメントの一部を現在作成中のドキュメントに取り込もうとする場合は、まず、上記他のドキュメントを表示部７ｂに表示する。そして、この表示部７ｂに表示したドキュメントから取り込む部分を指定することにより、そのドキュメントの参照情報を該当する項目に入力する。
【００７４】
また、ドキュメント内に絵を取り込んだり、用語辞書内の用語を引用したり、プログラムの一部を引用したりする場合も、上述した手順と同様にして行う。すなわち、上記絵、用語およびプログラムの各データが格納されている他データ記憶部４から所望のデータを取り出して表示部７ｂに表示し、必要な部分を指定することによって、対応する参照情報を該当する項目に入力する。
【００７５】
このように、データ量の多い画像データなどをドキュメント中に直接入力せずに、データ量の少ない参照情報を入力するようにすることにより、ドキュメント全体のデータ量を大幅に少なくすることができる。また、この参照情報によって関係付けられる一方の内容を変更したときに、それに連動して他方の内容も自動的に変更することができる。したがって、そのプロジェクト内で内容の統一されたドキュメントを作成することができるとともに、作成作業の手間を大幅に削減することができる。
【００７６】
なお、上述のように、他のドキュメント等からデータを取り込む際には、検索部１０を用いて、ドキュメント記憶部３や他データ記憶部４に既に格納されているデータを検索し、これにより取り出したデータを表示部７ｂに表示することも可能である。このようにすることにより、取り込もうとするデータを容易に見つけ出すことができるようになる。
【００７７】
さらに、本実施例では、外部ツール４０からの要求に応じて、ドキュメントを作成することができるようになされている。例えば、テストツールによるテスト結果をレポーティングする場合を考える。この場合、レポーティングのフォーマットはドキュメント定義部１によって定義可能であるが、その定義したドキュメントに入力すべきデータはテストツール側でしか知ることができない。
【００７８】
そこで、本実施例では、テストツールからの要求に応じてドキュメント管理システム２０を起動し、ドキュメント管理部５を介して所定のスクリプトを送ることによりドキュメント入力・修正部７を動作させる。そして、共通のデータベースに項目単位で格納されているドキュメントやその他のデータに対してデータを入力したり修正を加えたりしていくことによってドキュメントを作成することができるようにしている。
【００７９】
このように、本実施例によれば、本ドキュメント管理システム２０を直接操作することなく、個々の外部ツール４０から本ドキュメント管理システム２０を起動してドキュメントを作成することができるので、統合的な開発環境を実現することができる。
【００８０】
【発明の効果】
本発明は上述したように、各組織ごとに特有の文書体系に従ったドキュメント定義情報を作成し、このドキュメント定義情報に従って必要なドキュメント・インスタンスを作成し、作成したドキュメント・インスタンスにデータ入力を行ってドキュメントを生成することができるように構成したので、各組織ごとに特有の開発方法論に依存しない共通のドキュメント管理システムを使用することができるようになり、上記開発方法論に基づいて存在する文書体系ごとにドキュメント管理システムを開発しなくても済み、その開発および保守管理のための費用を節約することができる。
【００８１】
また、本発明は、ドキュメントが上記ドキュメント定義情報に基づく制約を満たすかどうかをチェックし、そのチェックの結果、制約を満たさないデータが入力されているドキュメントはデータ記憶手段に格納せずに、制約を満足するドキュメントのみをデータ記憶手段に格納するように構成したので、上記制約を満たす一定レベル以上の品質を有するドキュメントを常に作成することができるようになり、従来に比べてドキュメントの品質を大幅に向上させることができる。また、作成したドキュメントをドキュメント作成者が目視によって検査しなくても済むので、ドキュメントの生産性を向上させることもできる。
【００８２】
本発明の他の特徴によれば、ドキュメント入力手段で入力されるデータには、上記文書体系に含まれないデータに関する情報として、当該データが格納されている位置に関する参照情報を含むように構成したので、データ量の多い文書体系に含まれない例えば画像データ等をドキュメント中に直接入力せずに、データ量の少ない参照情報を入力することが可能となる。従って、ドキュメント全体のデータ量を大幅に少なくすることができる。また、この参照情報によって関連付けられる一方の内容を変更したときに、それに連動して他方の内容も自動的に変更することができる。従って、例えばそのプロジェクト内で内容の統一されたドキュメントを作成することができるとともに、作成作業の手間を大幅に削減することができる。
【図面の簡単な説明】
【図１】本発明の一実施例であるドキュメント管理システムの概略的な構成を示すブロック図である。
【図２】インスタンス作成部の概略的な構成を示すブロック図である。
【図３】ドキュメント入力・修正部の概略的な構成を示すブロック図である。
【図４】プロジェクトの型を定義するときに現れる画面の一例を示す図である。
【図５】サブシステム仕様書の文書型を定義するときに現れる画面の一例を示す図である。
【図６】図５に示した各フィールド内のデータの型等を定義するときに現れる画面の一例を示す図である。
【図７】異なるドキュメント間にある各項目の関係を示す図である。
【符号の説明】
１  ドキュメント定義部
２  ドキュメント定義情報記憶部
３  ドキュメント記憶部
４  他データ記憶部
５  ドキュメント管理部
６  インスタンス作成部
７  ドキュメント入力・修正部
８  制約管理部
９  ドキュメント出力部
１０  検索部
２０  ドキュメント管理システム
３０  他のドキュメント管理システム
４０  外部ツール
【図１】
0003704374.tif 000002
【図２】
0003704374.tif 000003
【図３】
0003704374.tif 000004
【図４】
0003704374.tif 000005
【図５】
0003704374.tif 000006
【図６】
0003704374.tif 000007
【図７】
0003704374.tif 000008