JP6283442B1 - 解析装置、解析方法、および解析プログラム - Google Patents

Abstract

【課題】ドキュメントを取り込み、一元的に管理する。
【解決手段】ドキュメントを解析する解析装置１であって、解析対象のドキュメントと、抽出対象のデータの複数の項目検索値と、前記データの読取方向とを受け付ける受付部１１と、前記ドキュメントから、前記項目検索値が設定されたセルを検索する検索部１２と、前記項目検索値毎に、当該項目検索値のセルから前記読取方向の各セルに設定されたデータを取得してドキュメントデータを生成する解析部１３と、を備える。解析部１３は、前記読取方向の各セルが表形式か否かを判別し、表形式でない場合、前記項目検索値のデータが終了したと判別する。
【選択図】図１

Description

本発明は、ドキュメントを解析する解析装置、解析方法、および解析プログラムに関する。

ドキュメントを解析する技術として、特許文献１には、ドキュメント・オブジェクト・モデル記述のコンテキストに基づいたトラバースのためのシステムが記載されている。特許文献１では、ドキュメント・オブジェクト・モデル記述として保存されたドキュメント・データを解析してドキュメント・オブジェクト・モデル・ノードを生成し、生成したドキュメント・オブジェクト・モデル・ノードに従って、ドキュメント・データをトラバースする。

特開２００８−１８１４８４号公報

アプリケーションプログラムの設計および開発において、設計書などのドキュメントが成果物として作成される。大量のドキュメントが作成された場合、ドキュメントのどこに何が書かれているかを把握するのは容易でないため、仕様変更、バグなどが発生した場合など、その影響範囲を大量のドキュメントから調査することは困難である。

また、ドキュメントは、様々なフォーマットで様々な情報が記述されているため、ドキュメントを一元的に管理することは難しい。

本発明は、上記事情に鑑みてなされたものであり、ドキュメントを取り込み、一元的に管理することを目的とする。

本発明は、ドキュメントを解析する解析装置であって、解析対象のドキュメントと、抽出対象のデータの複数の項目検索値と、前記データの読取方向とを受け付ける受付部と、前記ドキュメントから、前記項目検索値が設定されたセルを検索する検索部と、前記項目検索値毎に、当該項目検索値のセルから前記読取方向の各セルに設定されたデータを取得してドキュメントデータを生成する解析部と、を備え、前記解析部は、前記読取方向の各セルが表形式か否かを判別し、表形式でない場合、前記項目検索値のデータが終了したと判別する。

本発明は、ドキュメントを解析する解析方法であって、解析対象のドキュメントと、抽出対象のデータの複数の項目検索値と、前記データの読取方向とを受け付ける受付ステップと、前記ドキュメントから、前記項目検索値が設定されたセルを検索する検索ステップと、前記項目検索値毎に、当該項目検索値のセルから前記読取方向の各セルに設定されたデータを取得してドキュメントデータを生成する解析ステップと、を行い、前記解析ステップは、前記読取方向の各セルが表形式か否かを判別し、表形式でない場合、前記項目検索値のデータが終了したと判別する。

本発明は、ドキュメントを解析する解析プログラムであって、コンピュータに、解析対象のドキュメントと、抽出対象のデータの複数の項目検索値と、前記データの読取方向とを受け付ける受付ステップ、前記ドキュメントから、前記項目検索値が設定されたセルを検索する検索ステップ、および、前記項目検索値毎に、当該項目検索値のセルから前記読取方向の各セルに設定されたデータを取得してドキュメントデータを生成する解析ステップを実行させ、前記解析ステップは、前記読取方向の各セルが表形式か否かを判別し、表形式でない場合、前記項目検索値のデータが終了したと判別する。

本発明によれば、ドキュメントを取り込み、一元的に管理することができる。

本実施形態のドキュメント解析システムの構成例を示すブロック図である。 ドキュメント解析処理の一例を示すフローチャートである。 ドキュメントと、解析結果（ドキュメントデータ）の一例を示す図である。 リポジトリ生成処理の一例を示すフローチャートである。 進捗情報の一例を示す図である。 ソースコードの一例を示す図である。 ｏｐｅｎ数、ｃｌｏｓｅ数および乖離を集計したグラフである。 予測ソースコード行数と、実績ソースコード行数の推移を示すグラフである。 ＥＶＭ（Earned Value Management）の推移を示すグラフである。

以下、本発明の実施の形態について、図面を参照して説明する。

図１は、本発明の実施形態に係るドキュメント解析システムの全体を示すシステム構成図である。図示するドキュメント解析システムは、解析サーバ１と、ＤＢ（データベース）２とを備える。

解析サーバ１は、アプリケーションプログラムの設計書などのドキュメントを解析する装置であって、受付部１１と、検索部１２と、解析部１３と、生成部１４と、集計部１５とを備える。

受付部１１は、解析対象のドキュメントと、抽出対象のデータの複数の項目検索値と、前記データの読取方向とを受け付ける。また、受付部１１は、ドキュメントの中の表の付近に設定される表検索値および検索範囲を受け付けてもよい。また、受付部１１は、アプリケーションプログラムの進捗情報およびソースコードを受け付けてよい。

検索部１２は、ドキュメントから、項目検索値が設定されたセルを検索する。また、検索部１２は、項目検索値が設定されたセルを、表検索値が設定されたセルから検索範囲内で検索してもよい。

解析部１３は、項目検索値毎に、当該項目検索値のセルから前記読取方向の各セルに設定されたデータを取得してドキュメントデータを生成する。また、解析部１３は、読取方向の各セルが表形式か否かを判別し、表形式でない場合、項目検索値のデータが終了したと判別する。

生成部１４は、進捗情報、ソースコードおよびドキュメントデータの各レコードを、機能ＩＤとその他のデータとに編集して、進捗情報、ソースコードおよびドキュメントデータを統合したリポジトリ（各種のデータを一元的に纏めた、ファイルまたはデータベース）を生成する。この場合、項目検索値には、アプリケーションプログラムの機能ＩＤを含む。集計部１５は、リポジトリを、機能ＩＤ毎に集計する。

ＤＢ２には、入力された設計書などのドキュメント２１と、ドキュメント２１を解析して生成したドキュメントデータ２２と、入力された進捗情報２３およびソースコード２４と、ドキュメントデータ２２、進捗情報２３およびソースコード２４とに基づいて生成視されたリポジトリ２５とが格納されている。

上記説明した解析サーバ１は、例えば、ＣＰＵ（プロセッサ）と、メモリと、ハードディスク等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされた解析サーバ１用のプログラムを実行することにより、解析サーバ１の各機能が実現される。また、解析サーバ１用のプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ−ＲＯＭなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。なお、図１に示す解析サーバ１が、ＤＢ２を備えることとしてもよい。

次に、本実施形態のドキュメント解析方法を説明する。

図２は、本実施形態のドキュメント解析方法の一例を示すフローチャートである。ユーザは、解析対象のドキュメントおよび解析に必要な設定情報を解析サーバ１に入力する。

解析サーバ１の受付部１１は、解析対象のドキュメントの入力を受け付け、ＤＢ１２に格納する（Ｓ１１）。ドキュメントは、本実施形態では、アプリケーションプログラムの設計・開発に関するドキュメントであって、例えば設計書などである。また、ドキュメントは、一般的な表形式（例えば、エクセルなど表計算ソフト）のフォーマットで作成されていればよい。表形式のフォーマットは、データを入力するセルで構成されている。本実施形態では、ドキュメントのフォーマットに独自の制約がないため、既存の様々なドキュメントを対象とすることができる。

また、受付部１１は、設定情報として表検索値Ｔを受け付ける（Ｓ１２）。表検索値Ｔは、ドキュメントの中に記載された表（テーブル）を検索するための設定情報であって、後述する項目検索値Ｃ（ｍ）が設定されたセルの検索を容易にするためのものである。具体的には、ユーザは、ドキュメントの中に記載されている表の付近のセルに設定されている所定のデータ（文字列、文字、記号など）が存在する場合、当該所定のデータを表検索値Ｔとして入力する。なお、表検索値Ｔは必須の設定情報ではない。

また、受付部１１は、設定情報として複数の項目検索値Ｃ（ｍ）を受け付ける（Ｓ１３）。項目検索値Ｃは、表の項目名（見出し、ヘッダ）である。ｍは、ユーザが入力した項目検索値Ｃの数を示す。なお、本実施形態では、項目検索値Ｃ（ｍ）には、アプリケーションプログラムの各機能を識別するための機能ＩＤ（機能識別情報、機能名称など）が含まれている。

また、受付部１１、設定情報として読取範囲Ｒを受け付ける（Ｓ１４）。読取範囲Ｒは、項目検索値Ｃ（ｍ）の検索範囲であって、項目検索値Ｃ（ｍ）が設定されたセルの検索を容易にするための設定情報である。検索部１２は、表検索値Ｔが設定されたセルから読取範囲Ｒの範囲で、項目検索値Ｃ（ｍ）が設定されたセルを検索する。読取範囲Ｒには、例えば、表検索値Ｔが設定されたセルを基点として所定の大きさの領域（ｒ個のセル×ｓ個のセル）が設定される。なお、読取範囲Ｒは、必須の設定情報ではない。

また、受付部１１は、設定情報として読取方向Ｗを受け付ける（Ｓ１５）。読取方向Ｗには、項目検索値Ｃ（ｍ）が設定されたセルから、当該項目検索値Ｃ（ｍ）に対応するデータを読み取る方向（上下左右のいずれか１つ）が指定される。検索部１２は、項目検索値Ｃ（ｍ）のデータを取得する際に、項目検索値Ｃ（ｍ）が設定されたセルから、指定された読取方向Ｗ（例えば、下方向）に各セルのデータを読み込み、取得する。

そして、検索部１２は、Ｓ１１で入力されたドキュメント内を表検索値Ｔで検索することで、ドキュメントの中に記載された表を検索する（Ｓ１６）。具体的には、検索部１２は、表検索値Ｔに一致するデータが設定された全てのセルＸ（ｎ）の位置を取得する。ｎは、表検索値Ｔに一致するセルの数である。この場合、ドキュメントにはｎ個の表が存在すると想定される。検索部１２は、表検索値Ｔに一致するｎ個のセルＸ（ｎ）について、以降の処理を繰り返し行う。図２では、検索部１２がｉ（変数）に初期値「１」を設定することで（Ｓ１７）、セルＸ（１）〜セルＸ（ｎ）のｎ回の処理が行われる。

検索部１２は、ｉがｎ＋１より小さいか否か、すなわち、全てのセルＸ（ｎ）について処理を終了したか否かを判定する（Ｓ１８）。ｎ＋１より小さい場合（Ｓ１８：ＹＥＳ）、検索部１２は、セルＸ（ｉ）の位置をＹ（変数）に設定し（Ｓ１９）、Ｙの隣接セルの位置（座標）をＺ（変数）に設定する（Ｓ２０）。

そして、検索部１２は、隣接セルＺが表形式で、かつ、隣接セルＺが読取範囲Ｒ内か否かを判別する（Ｓ２１）。隣接セルＺが表形式か否かは、隣接セルＺが表の範囲内か否か、すなわち、隣接セルＺが表を構成しているか否かを意味する。例えば、検索部１２は、隣接セルＺの周囲の罫線の有無、または、隣接セルの塗りつぶし（ハッチング）の有無により、隣接セルＺが表形式か否かを判別する。具体的には、検索部１２は、隣接セルＺの周囲に罫線が引かれている場合、表形式であるとして判別し、隣接セルの周囲に罫線が引かれていない場合、表形式でないと判別する。また、検索部１２は、隣接セルＺが所定の色で塗りつぶされている場合、表形式であると判別し、隣接セルＺが所定の色で塗りつぶされていない場合、表形式でないと判別する。

Ｓ２１の２つの条件の少なくとも１つを満たさない場合（Ｓ２１：ＮＯ）、ｉに１を加算し（Ｓ３１）、Ｓ１８に戻り、次の表検索値Ｔ（ｉ）の処理を行う。

Ｓ２１の２つの条件の両方を満たす場合（Ｓ２１：ＹＥＳ）、検索部１２は、ｍ個の項目検索値Ｃ（ｍ）について、以降の処理を繰り返し行う。図２では、検索部１２は、ｊ（変数）に初期値「１」を設定することで（Ｓ２２）、ｍ回の処理が行われる。

検索部１２は、ｊがｍ＋１より小さいか否か、すなわち、全ての項目検索値Ｃ（ｍ）について処理を終了したか否かを判定する（Ｓ２３）。ｍ＋１より小さい場合（Ｓ２３：ＹＥＳ）、検索部１２は、隣接セルＺに設定されたデータが項目検索値Ｃ（ｊ）と一致するか否かを判別する（Ｓ２４）。

隣接セルＺのデータが項目検索値Ｃ（ｊ）と一致しない場合（Ｓ２４：ＮＯ）、検索部１２は、ｊに１を加算し（Ｓ３２）、Ｓ２３およびＳ２４の処理を繰り返し行う。隣接セルＺのデータが全ての項目検索値Ｃ（ｊ）と一致しない場合（Ｓ２３：ＮＯ）、検索部１２は、隣接セルＺに隣接する次の隣接セルの検索を行うために、隣接セルＺの位置をＹに設定し（Ｓ３３）、Ｓ２０に戻る。

隣接セルＺのデータが項目検索値Ｃ（ｊ）と一致する場合（Ｓ２４：ＹＥＳ）、解析部１３は、隣接セルＺの位置をＨ（変数）に設定し（Ｓ２５）、隣接セルＺのデータ（すなわち、項目検索値Ｃ（ｊ））を、ドキュメントデータとしてＤＢ２に出力する（Ｓ２６）。これにより、項目名（見出し、ヘッダー）が出力される。そして、解析部１３は、Ｈの位置のセルから読取方向Ｗに隣接するセルの位置をＤと設定し、セルＤが表形式か否かを判別する（Ｓ２８）。セルＤが表形式か否かは、Ｓ２１で説明したとおりである。解析部１３は、セルＤが表形式の場合（Ｓ２８：ＹＥＳ）、セルＤに設定されたデータを、Ｓ２６で出力した項目検索値Ｃ（ｊ）に対応付けて、ドキュメントデータとしてＤＢ２に出力する（Ｓ２９）。これにより、項目検索値Ｃ（ｊ）の項目名に対応するデータ（項目値）が出力される。

そして、解析部１３は、セルＤの位置をＨに設定し（Ｓ３０）、Ｓ２７に戻り、以降の処理をセルＤが表形式でなくなるまで繰り返し行う。セルＤが表形式でない場合（Ｓ２８：ＮＯ）、解析部１３は、項目検索値Ｃ（ｊ）の項目名に対応する全てのセルのデータが終了したと判別する。そして、解析部１３は、隣接セルＺに隣接する次の隣接セルの検索を行うために、隣接セルＺの位置をＹに設定し（Ｓ３３）、Ｓ２０に戻る。

以上説明した図２の処理により、設計書などの各種のドキュメントを解析し、ユーザが指定したに項目検索値Ｃ（ｊ）のデータを抽出したドキュメントデータ（ドキュメントのリポジトリ）を生成することができる。

図３は、図２の解析対象のドキュメントと、解析結果であるドキュメントデータの一例を示す図である。図３に示すドキュメント２１は、設計書の一部であって、３つ表が設定されている。ユーザは、表検索値Ｔに、各表の付近に設定された記号「＊」を設定する。また、ユーザは、項目検索値Ｃ（ｍ）に、「機能ＩＤ」、「機能」、「パラメータ」、「実行区分」を設定し、読取方向Ｗを「下方向」に設定する。表検索値Ｔには正規表現やワイルドカード指定が可能で、項目検索値Ｃ（ｍ）は複数の値を指定可能。項目検索値Ｃ（ｍ）は完全一致、部分一致を選択可能。これらの機能で項目名の揺らぎに対応することができる。

これにより、解析サーバ１は、図２の処理を行うことで、ドキュメント２１の解析結果であるドキュメントデータ２２を生成し、ＤＢ２に記憶する。このように、本実施形態では、ドキュメント２１の複数の表に分散して設定された各項目のデータを、１つのドキュメントデータ２２に統合することができる。

次に、図２の解析結果であるドキュメントデータと、進捗情報と、ソースコートとを統合したリポジトリを生成する処理を説明する。

図４は、リポジトリ生成処理の一例を示すフローチャートである。図示する例では、解析サーバ１は、ドキュメントデータ、進捗情報、およびソースコードを、機能ＩＤ単位で集計可能なように編集する。

解析サーバ１の受付部１１は、ユーザが入力した機能ＩＤの書式ＦＦ（データ形式、桁数など）を受け付ける（Ｓ５１）。そして、解析サーバ１は、進捗情報の処理（Ｓ６１〜Ｓ６８）、ドキュメントデータの処理（Ｓ７１〜Ｓ７８）、ソースコードの処理（Ｓ８１〜Ｓ８８）の処理をそれぞれ行う。

図５は、進捗情報の一例を示す図である。進捗情報は、アプリケーションプログラムの開発に必要に各種作業の進捗状況に関する情報である。図示する進捗情報は、機能ＩＤと、機能と、作業項目（例えば、画面設計書作成など）、作業開始日、作業終了日、終了フラグなどを対応づけた表形式のフォーマットで記述されている。

受付部１１は、ユーザが入力した進捗情報における機能ＩＤの定義箇所ＦＴを受け付ける（Ｓ６１）。機能ＩＤの定義箇所ＦＴは、進捗情報の中で機能ＩＤが設定されているセルの列、カラムなどである。図５に示す進捗情報の場合、受付部１１は、機能ＩＤの定義箇所ＦＴとして、１列目を受け付ける。

そして、受付部１４は、進捗情報の入力を受け付け、ＤＢ２に格納する（Ｓ６２）。進捗情報のレコードを、ここではＲｔ（ｎ）とする。ｎは、進捗情報のレコード数を示す。

そして、生成部１４は、ｉ（変数）に初期値「１」を設定し（Ｓ６３）、ｉがｎ＋１より小さいか否か、すなわち、全てのレコードについての処理を終了したか否かを判定する（Ｓ６４）。ｉがｎ＋１より小さい場合（Ｓ６４：ＹＥＳ）、生成部１４は、Ｒｔ（ｉ）における機能ＩＤの定義箇所ＦＴのセルに設定されたデータを、機能ＩＤの書式ＦＦで抽出し、Ｆとする（Ｓ６５）。

また、生成部１４は、Ｒｔ（ｉ）における機能ＩＤの定義箇所ＦＴ以外の各セルのデータをＸとし（Ｓ６６）、Ｒｔ（ｉ）を機能ＩＤのデータＦと、機能ＩＤ以外のデータＸとに編集して出力する（Ｓ６７）。そして、生成部１４は、ｉに１を加算し、Ｓ６４に戻り以降の処理をｎ回繰り返し行う。これにより、進捗情報の全てのレコードについて、機能ＩＤとその他のデータとが対応付けて、リポジトリとしてＤＢ２に出力される。

ドキュメントデータについては、受付部１１は、ユーザが入力したドキュメントデータにおける機能ＩＤの定義箇所ＦＤを受け付ける（Ｓ７１）。そして、生成部１４は、図２のドキュメント解析の解析結果であるドキュメントデータをＤＢ２から読み込む（Ｓ７２）。ドキュメントデータのレコードを、ここではＲｄ（ｍ）とする。ｍは、ドキュメントデータのレコード数を示す。

そして、生成部１４は、ｊ（変数）に初期値「１」を設定し（Ｓ７３）、変数ｊがｍ＋１より小さいか否か、すなわち、全てのレコードについての処理を終了したか否かを判定する（Ｓ７４）。ｊがｍ＋１より小さい場合（Ｓ７４：ＹＥＳ）、生成部１４は、Ｒｄ（ｊ）における機能ＩＤの定義箇所ＦＤのセルのデータを機能ＩＤの書式ＦＦで抽出し、Ｆとする（Ｓ７５）。

また、生成部１４は、Ｒｄ（ｊ）における機能ＩＤの定義箇所ＦＤ以外の各セルのデータをＹとし（Ｓ７６）、Ｒｄ（ｊ）を機能ＩＤのデータＦと、機能ＩＤ以外のデータＹとに編集して出力する（Ｓ７７）。そして、生成部１４は、ｊに１を加算し、Ｓ７４に戻り以降の処理をｍ回繰り返し行う。これにより、ドキュメントデータの全てのレコードについて、機能ＩＤとその他のデータとが対応付けて、リポジトリとしてＤＢ２に出力される。

図６は、アプリケーションプログラムのソースコード（ソースコードファイル）の一例を示す図である。受付部１１は、ユーザが入力したソースコードにおける機能ＩＤの定義箇所ＦＳを受け付ける（Ｓ８１）。また、受付部１４は、ソースコードの入力を受け付け、ＤＢ２に格納する（Ｓ８２）。なお、図６に示すように、機能ＩＤが設定されていないソースコードの場合、生成部１４は、ソースコードのファイル名などから機能ＩＤを取得し、ソースコードの各行（レコード）に機能ＩＤを補完して、表形式のフォーマットにソースコードを編集する（Ｓ８２）。ソースコードのレコードを、ここではＲｓ（ｌ）とする。ｌは、ソースコードのレコード数（行数）を示す。

そして、生成部１４は、変数ｋに初期値「１」を設定し（Ｓ８３）、ｋがｌ＋１より小さいか否か、すなわち、全てのレコードについての処理を終了したか否かを判定する（Ｓ８４）。ｋがｌ＋１より小さい場合（Ｓ８４：ＹＥＳ）、生成部１４は、Ｒｓ（ｋ）における機能ＩＤの定義箇所ＦＤのセルのデータを機能ＩＤの書式ＦＦで抽出し、Ｆとする（Ｓ８５）。

また、生成部１４は、Ｒｓ（ｋ）における機能ＩＤの定義箇所ＦＤ以外の各セルのデータ（ソースコード）をＺとし（Ｓ８６）、Ｒｓ（ｋ）を機能ＩＤのデータＦと、機能ＩＤ以外のデータＺとに編集して出力する（Ｓ７７）。そして、生成部１４は、ｋに１を加算し、Ｓ８４に戻り以降の処理をｌ回繰り返し行う。これにより、ソースコードの全てのレコードについて、機能ＩＤとその他のデータとが対応付けて、リポジトリとしてＤＢ２に出力される。

進捗情報の処理（Ｓ６１〜Ｓ６８）と、ドキュメントデータの処理（Ｓ７１〜Ｓ７８）と、ソースコードの処理（Ｓ８１〜Ｓ８８）とを行うことにより、ＤＢ２には、アプリケーションプログラムに関するリポジトリが生成される。すなわち、解析サーバ１は、進捗情報、ソースコードおよびドキュメントデータを統合し、機能ＩＤ毎に集計可能なリポジトリを構築する。

そして、集計部１５は、リポジトリを用いてアプリケーションプログラムに関する様々な管理情報を生成する（Ｓ９１）。

図７〜図９に、管理情報の例を示す。図７は、進捗情報を、機能ＩＤ毎に、ｏｐｅｎの数、ｃｌｏｓｅの数、および、乖離を集計したグラフである。ｏｐｅｎの数は、進捗情報の全レコード数（進捗管理の対象となる全作業項目の数）である。ｃｌｏｓｅの数は、進捗情報の中で作業が終了したレコードの数（例えば、終了フラグが設定されているレコードの数）である。乖離は、ｏｐｅｎの数からｃｌｏｓｅの数を減算した差分であって、終了していない作業項目の数を示す。集計部１５は、ＤＢ２のリポジトリから進捗情報を読み出し、ｏｐｅｎの数およびｃｌｏｓｅの数をカウントするとともに、乖離を算出して、図７に示すグラフを生成する。これにより、機能毎の進捗状況を容易に把握することができる。

図８は、ある機能ＩＤの予測ソースコード行数と、実績ソースコード行数の推移を示すグラフである。集計部１５は、予測ソースコード行数を、ＤＢ２のリポジトリのドキュメントデータを用いて取得する。具体的には、集計部１５は、指定された機能ＩＤのドキュメントデータのレコード数を所定の期日毎に集計（累積）し、集計したレコード数をｎ倍した値を予測ソースコード行数とする。これは、ドキュメントデータの１レコード（設計書の表の１行）に対して、ソースコードはｎ行作成されると仮定したものである。また、集計部１５は、実績ソースコード行数を、ＤＢ２のリポジトリのソースコードを用いて取得する。具体的には、集計部１５は、指定された機能ＩＤのソースコードのレコード数を所定の期日毎に集計（累積）した値を、実績ソースコード行数とする。

なお、リポジトリのドキュメントデータおよびソースコードの各レコードには、日付が設定されている、あるいは解析部１３または生成部１４により、データの更新履歴などから日付が補完されているものとする。図８に示すグラフにより、ある機能におけるソースコードの作成状況を容易に把握することができる。

図９は、ある機能ＩＤのＥＶＭ（Earned Value Management）のグラフである。ＥＶＭは、プロジェクトマネージメントにおいて進捗状況の管理を行う手法であって、作業の到達度をコストなどの価値に換算したＥＶ（Earned Value:出来高）の指標で把握する。ＰＶ（Planned Value：計画値）は、予定工数を所定の期日ごとに集計したものである。ＥＶは、予定工数×進捗率の増減分を、所定の期日ごとに集計したものである。ＡＣ（Actual Cost：実績値）は、実際にかかった工数を期日ごとに集計したものである。ＥＶＭでは現在のコスト・スケジュールの両方の進捗状況を統一的な尺度で把握することができ、また、ある時点での計画とのズレの大きさから、完成までの総時間・総コストを予測することもできる。

以上説明した本実施形態では、解析対象のドキュメントと、抽出対象のデータの複数の項目検索値と、前記データの読取方向とを受け付ける受付部と、前記ドキュメントから、前記項目検索値が設定されたセルを検索する検索部と、前記項目検索値毎に、当該項目検索値のセルから前記読取方向の各セルに設定されたデータを取得してドキュメントデータを生成する解析部と、を備え、前記解析部は、前記読取方向の各セルが表形式か否かを判別し、表形式でない場合、前記項目検索値のデータが終了したと判別する。

これにより、本実施形態では、ドキュメントを取り込み、一元的に管理すること、すなわちドキュメントのリポジトリを構築することができる。具体的には、設計書などの各種のドキュメントを解析し、ユーザが指定したに項目検索値Ｃ（ｍ）のデータを抽出したドキュメントデータを生成することができる。

このため、本実施形態では、ドキュメントが大量にある場合であっても、仕様変更、バグなどが発生した場合などに、その影響範囲の調査に要する工数を削減し、アプリケーションプログラムの生産性を向上するとともに、品質を向上することができる。

また、本実施形態のドキュメントは、一般的な表形式（例えば、エクセルなど表計算ソフト）のフォーマットで作成されていればよく、ドキュメントのフォーマットに独自の制約がないため、これから新規に作成するドキュメントだけでなく、既存のドキュメントも対象とすることができる。

また、本実施形態では、ドキュメントの中の表の付近に設定される表検索値および検索範囲を受け付け、項目検索値が設定されたセルを、表検索値が設定されたセルから検索範囲内で検索する。これにより、本実施形態では、項目検索値Ｃ（ｍ）が設定されたセルを、容易に検索することができる。

また、本実施形態では、進捗情報、ソースコードおよびドキュメントデータの各レコードを、機能ＩＤとその他のデータとに編集して、進捗情報、ソースコードおよびドキュメントデータを統合したリポジトリを生成する。これにより、アプリケーションプログラムに関する情報を一元管理し、全体の関連性や、品質などを見える化し、生産性および品質を向上することができる。

また、本実施形態では、リポジトリを、機能ＩＤ毎に集計することで、アプリケーションプログラムの機能毎に、定量的な進捗管理や、生産性を容易に把握することができる。

なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

１ ：解析サーバ
１１：受付部
１２：検索部
１３：解析部
１４：生成部
１５：集計部
２ ：ＤＢ（データベース）

Claims (3)

1. ドキュメントを解析する解析装置であって、
   解析対象のドキュメントと、抽出対象のデータの複数の項目検索値と、前記データの読取方向とを受け付ける受付部と、
   前記ドキュメントから、前記項目検索値が設定されたセルを検索する検索部と、
   前記項目検索値毎に、当該項目検索値のセルから前記読取方向の各セルに設定されたデータを取得してドキュメントデータを生成する解析部と、を備え、
   前記解析部は、前記読取方向の各セルが表形式か否かを判別し、表形式でない場合、前記項目検索値のデータが終了したと判別し、
   前記受付部は、前記ドキュメントの中の表の付近に設定される表検索値および検索範囲を受け付け、
   前記検索部は、前記項目検索値が設定されたセルを、前記表検索値が設定されたセルから前記検索範囲内で検索すること
   を特徴とする解析装置。
2. ドキュメントを解析する解析方法であって、
   解析対象のドキュメントと、抽出対象のデータの複数の項目検索値と、前記データの読取方向とを受け付ける受付ステップと、
   前記ドキュメントから、前記項目検索値が設定されたセルを検索する検索ステップと、
   前記項目検索値毎に、当該項目検索値のセルから前記読取方向の各セルに設定されたデータを取得してドキュメントデータを生成する解析ステップと、を行い、
   前記解析ステップは、前記読取方向の各セルが表形式か否かを判別し、表形式でない場合、前記項目検索値のデータが終了したと判別し、
   前記受付ステップは、前記ドキュメントの中の表の付近に設定される表検索値および検索範囲を受け付け、
   前記検索ステップは、前記項目検索値が設定されたセルを、前記表検索値が設定されたセルから前記検索範囲内で検索すること
   を特徴とする解析方法。
3. ドキュメントを解析する解析プログラムであって、
   コンピュータに、
   解析対象のドキュメントと、抽出対象のデータの複数の項目検索値と、前記データの読取方向とを受け付ける受付ステップ、
   前記ドキュメントから、前記項目検索値が設定されたセルを検索する検索ステップ、および、
   前記項目検索値毎に、当該項目検索値のセルから前記読取方向の各セルに設定されたデータを取得してドキュメントデータを生成する解析ステップを実行させ、
   前記解析ステップは、前記読取方向の各セルが表形式か否かを判別し、表形式でない場合、前記項目検索値のデータが終了したと判別し、
   前記受付ステップは、前記ドキュメントの中の表の付近に設定される表検索値および検索範囲を受け付け、
   前記検索ステップは、前記項目検索値が設定されたセルを、前記表検索値が設定されたセルから前記検索範囲内で検索すること
   を特徴とする解析プログラム。

Images