JP5926672B2 - 開発資産管理装置、開発支援方法及び開発支援プログラム - Google Patents

Description

本発明は、開発資産管理装置、開発支援方法及び開発支援プログラムに関する。

アプリケーションの開発は、設計、製造、テストといった工程に分けて作業がなされる。一般に、開発の作業によって得られた開発成果物は、工程と同様の階層構造を持つディレクトリに配置することによって管理される。この他、工程とは異なる観点の階層構造へ開発成果物を仮想的に分類した上で分類後の階層構造にしたがって開発成果物を表示させる技術も提案されている。

特開平０９−１６７０８７号公報 特開２００４−２５２７１９号公報 特開２００８−３１０４６１号公報

しかしながら、上記の従来技術は、以下に説明するように、アプリケーションの開発に携わる開発関係者が目的の開発成果物にたどりつくのが困難であるという問題がある。

すなわち、上記の従来技術は、開発プロジェクトの工程の名称を始め、設計書のドキュメントの命名規約やソースコードのコーディング規約などの開発規約に精通した熟練者を想定して分類を行うものに過ぎない。ところが、開発関係者は、必ずしも熟練者ばかりではなく、開発規約に不慣れな初心者も存在する。このため、熟練者は、階層的に表示されたディレクトリを開発規約にしたがって探索することで目的の開発成果物にたどりつくことができたとしても、初心者は目的の開発成果物にたどりつくことができない場合もある。このように、初心者である開発関係者は、開発成果物を参照したり、あるいは編集したりすることができず、開発の作業効率が低下してしまうおそれがある。

開示の技術は、上記に鑑みてなされたものであって、開発関係者が目的の開発成果物を容易に探索できる開発資産管理装置、開発支援方法及び開発支援プログラムを提供することを目的とする。

本願の開示する開発資産管理装置は、アプリケーションの開発作業による成果として得られる開発成果物の集合である開発資産を収集する収集部と、前記収集部によって収集される開発資産のうち、前記開発資産の体系が機能によって定義された機能定義ファイルから各開発成果物の機能を辞書化することによって機能辞書を作成する作成部と、前記収集部によって収集された開発資産のうち前記機能定義ファイル以外の開発成果物を対象に、当該開発成果物に割り当てられた機能を前記機能辞書を用いて特定するとともに、前記開発作業の工程が辞書化された工程辞書を記憶する辞書記憶部を用いて当該開発成果物が割り当てられた工程を特定する特定部と、前記特定部によって特定された開発成果物の機能および工程を対応付けることによって前記開発資産の構造が辞書化された構造辞書を生成する生成部と、前記機能の指定を受け付けた場合には、前記構造辞書を参照して、前記開発資産に含まれる各開発成果物を機能によってグルーピングした上で同一の機能にグルーピングされた開発成果物を前記工程によってグルーピングした開発資産の階層構造を表示させ、前記工程の指定を受け付けた場合には、前記構造辞書を参照して、前記開発資産に含まれる各開発成果物を工程によってグルーピングした上で同一の工程にグルーピングされた開発成果物を前記機能によってグルーピングした開発資産の階層構造を表示させる表示制御部とを有する。

本願の開示する開発資産管理装置の一つの態様によれば、開発関係者が目的の開発成果物を容易に探索できるという効果を奏する。

図１は、実施例１に係る開発資産管理装置の機能的構成を示すブロック図である。 図２は、開発資産の階層構造を模式化した模式図である。 図３は、開発資産に含まれるファイルの一例を示す図である。 図４は、収集設定情報の構成例を示す図である。 図５は、分類キー情報の一例を示す図である。 図６は、分類キー情報の一例を示す図である。 図７は、サブシステム情報の一例を示す図である。 図８は、タスク情報の一例を示す図である。 図９は、ターゲット資産情報の一例を示す図である。 図１０は、分析情報の一例を示す図である。 図１１は、エクスプローラ定義情報の一例を示す図である。 図１２は、クライアント端末に表示される画面の一例を示す図である。 図１３は、クライアント端末に表示される画面の一例を示す図である。 図１４は、ナビゲーション定義情報の一例を示す図である。 図１５は、実施例１に係る開発資産収集処理の手順を示すフローチャートである。 図１６は、実施例１に係る分類キー情報作成処理の手順を示すフローチャートである。 図１７は、実施例１に係る構造ディクショナリ生成処理の手順を示すフローチャートである。 図１８は、実施例１に係る開発支援処理の手順を示すフローチャートである。 図１９は、実施例１及び実施例２に係る開発支援プログラムを実行するコンピュータの一例について説明するための図である。

以下に、本願の開示する開発資産管理装置、開発支援方法及び開発支援プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［開発資産管理装置の構成］
図１は、実施例１に係る開発資産管理装置の機能的構成を示すブロック図である。図１に示す開発資産管理装置１００は、アプリケーションの開発によって得られる開発成果物の集合である開発資産を管理するものである。とりわけ、開発資産管理装置１００は、開発成果物を分類可能なインデックスを辞書化した構造ディクショナリを生成した上で、構造ディクショナリを用いてクライアント端末３０から指定される観点に合わせて開発資産を分類した上で開発資産の一覧を階層的に表示させるアプリケーションの開発支援サービスを提供する。

かかる開発資産管理装置１００の一態様としては、上記の開発支援サービスを提供するＷｅｂサーバとして実装することとしてもよいし、また、アウトソーシングによって上記の開発支援サービスを提供するクラウドとして実装することもできる。他の一態様としては、パッケージソフトウェアやオンラインソフトウェアとして提供される開発支援プログラムを所望のコンピュータにプリインストール又はインストールさせることによっても実装できる。

図１に示す開発資産管理装置１００は、所望のネットワークを介して、クライアント端末３０と相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット（Internet）、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。

クライアント端末３０は、上記の開発支援サービスの提供を受けるコンピュータである。例えば、クライアント端末３０は、アプリケーションの開発に携わる開発関係者によって使用される。かかるクライアント端末３０の一態様としては、パーソナルコンピュータを始めとする固定端末の他、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistants）などの移動体端末も採用できる。

図１に示すように、開発資産管理装置１００は、通信Ｉ／Ｆ（interface）部１１０と、記憶部１３０と、制御部１５０とを有する。なお、開発資産管理装置１００は、図１に示した機能部以外にも既知のサーバ装置が有する各種の機能部、例えば各種の入出力デバイスなどを有することとしてもかまわない。

通信Ｉ／Ｆ部１１０は、他の装置、例えばクライアント端末３０との間で通信制御を行うインタフェースである。かかる通信Ｉ／Ｆ部１１０の一態様としては、ＬＡＮカードなどのネットワークインタフェースカードを採用できる。例えば、通信Ｉ／Ｆ部１１０は、クライアント端末３０から開発資産の閲覧要求を受け付けたり、開発資産の一覧画面をクライアント端末３０に送信したりする。

記憶部１３０は、制御部１５０で実行されるＯＳ（Operating System）や開発支援プログラムなどの各種プログラムを記憶する記憶デバイスである。記憶部１３０の一態様としては、フラッシュメモリなどの半導体メモリ素子、ハードディスク、光ディスクなどの記憶装置が挙げられる。また、記憶部１３０は、上記の種類の記憶装置に限定されるものではなく、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory)であってもよい。記憶部１３０は、制御部１５０で実行されるプログラムに用いられるデータの一例として、後述する開発資産情報１３１、収集設定情報１３２、分類キー情報１３３、構造ディクショナリ１３４、エクスプローラ定義情報１３５やナビゲーション定義情報１３６などを記憶する。

制御部１５０は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１５０は、図１に示すように、クローラ１６０と、エクスプローラ１７０と、ナビゲータ１８０とを有する。

クローラ１６０は、開発成果物を分類可能なインデックスを辞書化した構造ディクショナリを生成するソフトウェア、すなわち「クローラ」を実行する処理部である。一態様としては、クローラ１６０は、アプリケーションの開発プロジェクトの「工程」やアプリケーションが実現する「機能」を始めとする複数の観点で開発成果物を分類できるように、開発成果物ごとに工程ＩＤおよび機能ＩＤなどの複数のインデックスが対応付けられた構造ディクショナリを生成する。クローラ１６０は、図１に示すように、収集部１６１と、分類キー情報作成部１６２と、構造ディクショナリ生成部１６３とを有する。

収集部１６１は、収集設定情報１３２にしたがって開発資産情報１３１に含まれる開発資産を収集する処理部である。一態様としては、収集部１６１は、クライアント端末３０によって開発資産情報１３１に含まれる開発成果物が更新された場合に、記憶部１３０に記憶された収集設定情報１３２のうち当該更新が実行されたサブシステムに関する開発資産の収集設定を読み出す。ここで、収集部１６１は、先に読み出した収集設定のうちサブシステム全体の体系が定義された定義ファイルを含むタスクの収集設定、すなわち「設計ディクショナリ」に関する収集設定に定義された開発資産の配置場所、例えば開発成果物であるファイルが格納されたディレクトリの所在を示すパスを参照して、「設計ディクショナリ」に関するファイルを優先して収集する。その後、収集部１６１は、「設計ディクショナリ」以外の収集設定について収集が終了するまでファイルの収集を繰り返し実行する。なお、ここでは、開発成果物の更新が実行されたサブシステムに関する開発資産をリアルタイムに収集する場合を例示したが、一定期間、例えば１分間や１時間が経過することをトリガーとして開発資産の収集を開始することとしてもかまわない。

ここで、収集部１６１が収集する開発資産および収集部１６１が収集時に参照する収集設定について説明する。以下では、一例として、販売管理のサブシステムに関する開発資産が収集される場合を想定して説明を行う。

図２は、開発資産の階層構造を模式化した模式図であり、図３は、開発資産に含まれるファイルの一例を示す図である。図２及び図３には、一例として、サブシステム「販売管理（SalesManagement）」に関する開発資産が図示されている。図２に示すように、販売管理の開発資産は、「設計資産」、「ソースコード資産」及び「プロダクト資産」に分類される。このうち、「設計資産」は、「設計書」および「設計ディクショナリ」へさらに分類される。また、「ソースコード資産」は、「画面デザインコード」、「帳票デザインコード」、「自動生成コード」、「ロジックコード」および「カスタマイズコード」へさらに分類される。また、「プロダクト資産」は、「Ｗｅｂサービス」、「Ｗｅｂアプリケーション」および「スマートクライアント」へさらに分類される。

このうち、設計書には、図３に示すように、要件定義（ＲＤ：Requirements Definition）、ユーザインタフェース設計（ＵＩ：User Interface design）、システム構造設計（ＳＳ：System Structure design）、プログラム構造設計（ＰＳ：Program Structure design）などの各種の設計書が含まれる。かかる設計書のファイル例としては、「販売管理メニュー設計.xlsx」や「受注入力画面ＵＩ設計書.xls」などのドキュメントが挙げられる。また、設計ディクショナリには、図３に示すように、機能一覧定義、ドメイン定義やメッセージ定義などの定義情報が含まれる。かかる設計ディクショナリのファイル例としては、「機能一覧定義.xml」、「機能ドメイン定義.xml」および「メッセージ定義.xml」などが挙げられる。同様に、ソースコード資産やプロダクト資産についても、図３に示す各種のファイルが存在する。これらのファイルの集合が開発資産情報１３１として記憶部１３０に記憶されている。

図４は、収集設定情報１３２の構成例を示す図である。図４には、販売管理のサブシステムに関する開発資産の収集設定が図示されている。図４に示すように、収集設定情報１３２の一例としては、タスク名、分類、詳細分類、配置場所、管理対象条件および備考が対応付けられたデータを採用できる。ここで言う「管理対象条件」とは、開発資産のうち上記の構造ディクショナリとして管理させるファイルの条件を指し、例えば、ファイルの拡張子に関する条件、ファイル名に関する条件やその他の条件が設定される。なお、ここでは、収集設定情報１３２が記憶部１３０に予め登録されている場合を例示したが、収集の都度、外部装置から取得することとしてもかまわない。

例えば、図４の例で言えば、収集部１６１は、他のタスクに優先してタスク名「設計ディクショナリ」の収集を開始する。すなわち、収集部１６１は、相対パス「\subsys\dic」が示すディレクトリの配下に全てのファイルを収集する。このとき、収集部１６１は、相対パス「\subsys\dic」が示すディレクトリ内にあるファイルだけでなく、当該ディレクトリよりも下位にある全てのディレクトリ内のファイルを収集する。その後、収集部１６１は、タスク名「設計ディクショナリ」以外のタスクに関する収集を開始する。例えば、開発資産のうちタスク名「設計文書」に関する開発成果物を収集する場合には、収集部１６１は、相対パス「\subsys\doc」が示すディレクトリの配下に全てのファイルを収集する。このとき、収集部１６１は、相対パス「\subsys\doc」が示すディレクトリ内にあるファイルだけでなく、当該ディレクトリよりも下位にある全てのディレクトリ内のファイルを収集する。このようにして全てのタスクに関する開発資産の収集が図４に示す収集設定にしたがって実行される。なお、図４の例では、配置場所として相対パスを例示したが、絶対パスで表現された配置場所を参照することとしてもかまわない。

分類キー情報作成部１６２は、収集部１６１によって収集されたファイルのうち所定の定義ファイルから、開発成果物を分類するキーとする分類キー情報を作成する処理部である。

一態様としては、分類キー情報作成部１６２は、収集部１６１によって収集されたタスク名「設計ディクショナリ」の収集ファイルのファイル名と所定の定義ファイルのファイル名とが一致するか否かを判定する。かかる定義ファイルとは、サブシステム全体の体系が定義された定義情報であり、例えば、「機能一覧定義」、「ドメイン定義」、「エンティティ定義」や「メッセージ定義」などが挙げられる。このとき、両者のファイル名は、必ずしも完全一致する必要はなく、前方一致または後方一致などの部分一致であれば定義ファイルと判別することとしてもよく、定義ファイルのファイル名の正規表現と比較することとしてもよい。ここで、分類キー情報作成部１６２は、収集ファイルのファイル名が定義ファイルのファイル名と一致する場合には、定義ファイルの種類に応じて分類キー情報１３３を作成した上で記憶部１３０へ登録する。一方、分類キー情報作成部１６２は、収集ファイルのファイル名が定義ファイルのファイル名と一致しない場合には、分類キー情報の作成は実行されない。そして、分類キー情報作成部１６２は、収集部１６１によって収集されたタスク名「設計ディクショナリ」に関する全ての収集ファイルを対象に、上記の分類キー情報の作成を実行する。

図５及び図６は、分類キー情報の一例を示す図である。図５には、サブシステム「販売管理」が有する機能が定義された機能一覧定義ファイルから作成された分類キー情報の一例を図示している。図６には、サブシステム「販売管理」が有するエンティティが定義されたエンティティ定義ファイルから作成された分類キー情報の一例が図示されている。

図５に示すように、収集ファイルが機能一覧定義ファイルである場合には、機能を識別する「機能ＩＤ（identification）」を始め、機能の名称を表す「機能名」および機能の種別を表す「機能種別」が対応付けられた情報が分類キー情報として作成される。例えば、機能一覧定義ファイルがＸＭＬ（Extensible Markup Language）で記述されているとしたとき、定義ファイルに含まれるタグ「機能ＩＤ」、「機能名」及び「機能種別」が検索される。このとき、タグ「機能ＩＤ」、「機能名」及び「機能種別」に記述された値として、例えば、「SCR0010」、「受注入力機能」及び「画面」が抽出された場合には、「SCR0010」、「受注入力機能」及び「画面」が対応付けられた情報が分類キー情報として作成される。以降、同様に、図５に示す分類キー情報が作成される。図６に示すように、エンティティ定義ファイルである場合には、エンティティを識別する「エンティティＩＤ」とエンティティの名称を表す「エンティティ名」とが対応付けられた情報が分類キー情報として作成される。例えば、エンティティ定義ファイルがＸＭＬで記述されているとしたとき、定義ファイルに含まれるタグ「エンティティＩＤ」及び「エンティティ名」が検索される。このとき、タグ「エンティティＩＤ」及び「エンティティ名」に記述された値として、例えば、「JyuchuTBL」及び「受注ジャーナルテーブル」が抽出された場合には、「JyuchuTBL」及び「受注ジャーナルテーブル」が対応付けられた情報が分類キー情報として作成される。以降、同様に、図６に示す分類キー情報が作成される。なお、ここでは、分類キー情報としてＩＤ以外にも名前や種別を抽出する場合を例示したが、必ずしも全てを抽出する必要はなく、例えば、定義ファイルごとにＩＤだけを抽出するようにしてもよい。

なお、図５及び図６の例では、機能一覧定義ファイルから作成された分類キー情報およびエンティティ定義ファイルから作成された分類キー情報を例示したが、分類キー情報は図５及び図６のものに限定されない。すなわち、詳細は図８を用いて後述するが、図５及び図６に示す分類キー情報の他にも、タスクＩＤおよび工程ＩＤが対応付けられたタスク情報が分類キー情報としてあらかじめ登録されている。

構造ディクショナリ生成部１６３は、分類キー情報１３３を用いて、収集部１６１によって収集されたファイルから、開発成果物を分類可能なインデックスを辞書化した「構造ディクショナリ」を生成する処理部である。

一態様としては、構造ディクショナリ生成部１６３は、収集部１６１によって収集されたタスク名「設計ディクショナリ」以外の他のタスク名の収集ファイルが収集設定に定義された管理対象条件を満たすか否かを判定する。例えば、図４の例で言えば、タスク名「設計文書」に関する収集設定にしたがって開発成果物を収集している場合には、拡張子が「xls,Xlsx」であることが条件として定義されるとともに文章タイトルが「ＸＸＸ」であることが定義されている。この場合には、構造ディクショナリ生成部１６３は、収集ファイルの拡張子が「xls,Xlsx」であり、かつ収集ファイルのプロパティに記述された文書タイトルが「ＸＸＸ」であるか否かを判定する。このとき、収集ファイルの拡張子が「xls,Xlsx」であり、かつ収集ファイルのプロパティに記述された文書タイトルが「ＸＸＸ」である場合に、当該収集ファイルが管理対象条件を満たすと判定される。また、タスク名「帳票」に関する収集設定にしたがって開発成果物を収集している場合には、拡張子が「rdl」であることが条件として定義されるとともにファイル名が「帳票定義」であることが定義されている。この場合には、構造ディクショナリ生成部１６３は、収集ファイルの拡張子が「rdl」であり、かつ収集ファイルのファイル名が「帳票定義」であるか否かを判定する。このとき、収集ファイルの拡張子が「rdl」であり、かつ収集ファイルのファイル名が「帳票定義」である場合に、当該収集ファイルが管理対象条件を満たすと判定される。この他の収集設定についても、図４に示した管理対象条件を満たすか否かが同様に判定される。

そして、構造ディクショナリ生成部１６３は、収集ファイルが管理対象条件を満たす場合に、当該収集ファイルのサブシステム情報を取得する。かかるサブシステム情報の一例としては、開発成果物の更新が実行されたサブシステム、すなわち開発資産の収集が実行されたサブシステムのサブシステムＩＤやサブシステム名が自動的に取得される。図７は、サブシステム情報の一例を示す図である。図７に示すように、開発資産管理装置１００が管理する開発資産には、基盤「Framework」、共通「SystemFrame」、会計「GeneralLedger」、手形「Bill」、人事給与「SalaryCalculation」や販売管理「SalesManagement」などが含まれる。このうち、開発資産の収集が実行されているサブシステムは、販売管理であるので、サブシステムＩＤ「SalesManagement」及びサブシステム名「販売管理」がサブシステム情報として取得される。

続いて、構造ディクショナリ生成部１６３は、分類キー情報１３３を用いて、収集ファイルに採番されている各種ＩＤ、例えば工程ＩＤ、タスクＩＤ、機能ＩＤやエンティティＩＤなどを特定する。

これを具体的に説明すると、構造ディクショナリ生成部１６３は、分類キー情報１３３の一例としてタスク情報のマスタテーブルを参照して、収集ファイルのタスクＩＤおよび工程ＩＤを特定する。図８は、タスク情報の一例を示す図である。図８に示すタスク情報の一態様としては、タスクを識別する「タスクＩＤ」、タスクの名称を表す「タスク名」及び工程を識別する「工程ＩＤ」が対応付けられた情報を採用できる。かかるタスク情報のマスタテーブルに設けられたフィールドのうちタスク名は、図４に示した収集設定のフィールド「詳細分類」に対応する。例えば、図４に示した収集設定のうちタスク名「設計文書」に関する収集設定にしたがって開発成果物を収集している場合には、当該収集設定の詳細分類「設計文書」に対応するタスクＩＤおよび工程ＩＤが図８に示すタスク情報のマスタテーブルから検索される。このとき、図８に示すように、収集が実行中である収集設定に定義された詳細分類「設計文書」がタスク情報のマスタテーブルのレコードのうち上から１番目のレコードのタスク名「設計文書」と一致する。この場合には、当該１番目のレコードのタスクＩＤ「document」及び工程ＩＤ「design」が取得されることになる。

これらタスクＩＤ及び工程ＩＤの他、構造ディクショナリ生成部１６３は、図５に示した機能一覧定義ファイルから作成された分類キー情報を用いて、収集ファイルの機能ＩＤを特定したり、図６に示したエンティティ定義ファイルから作成された分類キー情報を用いて、収集ファイルのエンティティＩＤを特定したりする。

例えば、機能ＩＤを特定する場合には、構造ディクショナリ生成部１６３は、収集ファイルに含まれる文字列と、図５に示した分類キー情報に含まれる機能ＩＤ及び機能名との間でパターンマッチングを実行する。このとき、機能ＩＤ「SCR0010」または機能名「受注入力機能」と一致する文字列が収集ファイルに含まれる場合には、構造ディクショナリ生成部１６３は、当該収集ファイルの機能ＩＤが「SCR0010」であると特定する。また、機能ＩＤ「CHU0020」または機能名「注文書類作成機能」と一致する文字列が収集ファイルに含まれる場合には、当該収集ファイルの機能ＩＤが機能ＩＤ「CHU0020」であると特定する。なお、１つの収集ファイルに複数の機能ＩＤや機能名が含まれる場合には、複数の機能ＩＤを抽出すればよい。

また、エンティティＩＤを特定する場合には、構造ディクショナリ生成部１６３は、収集ファイルに含まれる文字列と、図６に示した分類キー情報に含まれるエンティティＩＤ及びエンティティ名との間でパターンマッチングを実行する。このとき、エンティティＩＤ「JyuchuTBL」またはエンティティ名「受注ジャーナルテーブル」と一致する文字列が収集ファイルに含まれる場合には、構造ディクショナリ生成部１６３は、当該収集ファイルのエンティティＩＤが「JyuchuTBL」であると特定する。また、エンティティＩＤ「ShohinMST」またはエンティティ名「商品マスタテーブル」と一致する文字列が収集ファイルに含まれる場合には、当該収集ファイルのエンティティＩＤがエンティティＩＤ「ShohinMST」であると特定する。なお、１つの収集ファイルに複数のエンティティＩＤやエンティティ名が含まれる場合には、複数のエンティティＩＤを抽出すればよい。

なお、ここでは、収集ファイルに含まれる文字列と、図５及び図６に示したＩＤや名称との間でパターンマッチングを実行することによって機能ＩＤやエンティティＩＤを特定する場合を例示したが、機能ＩＤやエンティティＩＤの特定方法はこれに限定されない。例えば、収集ファイルのフォーマットで機能ＩＤやエンティティＩＤが記述される箇所が予め固定的に定められている場合には、パターンマッチングを実行せずとも、フォーマットで定められた箇所を参照することによって機能ＩＤやエンティティＩＤを取得することとしてもよい。

このように、収集ファイルの各種ＩＤが特定されると、構造ディクショナリ生成部１６３は、先に特定した各種ＩＤを収集ファイルに対応付けることによってターゲット資産情報１３４ａを生成する。例えば、構造ディクショナリ生成部１６３は、当該収集ファイルの配置場所である資産相対パス、収集ファイルのファイル名、収集ファイルの拡張子、収集ファイルの資産種別、収集ファイルが属するサブシステム、機能ＩＤ、エンティティＩＤ及びタスクＩＤを対応付けたターゲット資産情報１３４ａを生成する。その上で、構造ディクショナリ生成部１６３は、先に生成されたターゲット資産情報１３４ａを記憶部１３０へ登録する。なお、ここでは、タスク情報のマスタテーブルを用いて、タスクＩＤから工程ＩＤを抽出できるので、工程ＩＤの登録を省略しているが、工程ＩＤをさらに対応付けてターゲット資産情報を生成した上で記憶部１３０へ登録することもできる。

図９は、ターゲット資産情報１３４ａの一例を示す図である。図９には、販売管理のサブシステムに関する開発資産から生成されたターゲット資産情報１３４ａを図示している。例えば、図９に示す上から１番目のレコードは、ファイル名「受注入力画面設計書.xls」の収集ファイルが資産相対パス「\subsys\doc\」に配置されており、当該受注入力画面設計書.xlsの機能ＩＤが「SCR0010」であり、エンティティＩＤが「JuchuTBL」及び「ChumonTBL」であり、かつタスクＩＤが「document」であることを示す。また、図８に示したタスク情報のマスタテーブルには、タスクＩＤ「document」と工程ＩＤ「design」が対応付けられているので、当該収集ファイルは工程ＩＤ「design」とさらに対応付けられているとも言える。このように、ターゲット資産情報１３４ａには、ファイル名と各種ＩＤとが対応付けられているので、ファイルを機能によって分類することもできるし、エンティティによって分類することもできるし、タスクによって分類することもできるし、工程によって分類することもできる。

かかるターゲット資産情報１３４ａの登録後に、構造ディクショナリ生成部１６３は、当該収集ファイルの内容を解析することによって分析情報を生成する。ここで、解析内容は、収集ファイルのタスクに応じて変更される。例えば、収集ファイルのタスク名が「アセンブリ情報」である場合には、ＤＬＬ（Dynamic Link Library）ファイルやＥＸＥファイルを逆アセンブルで解析する。かかる逆アセンブルによって、例えば、収集ファイルのクラスを解析したり、クラスに含まれるメソッドを解析したり、メソッドの中でどのようなクラスのメソッドを呼び出しているのかを呼出先クラスメソッドとして解析したり、さらには、呼び出すメソッドがどのクラスに依存しているのかを依存クラスとして解析したりすることができる。これらクラス、メソッド、呼出先クラスメソッド及び依存クラスがファイル名に対応付けられることによって分析情報１３４ｂが生成される。また、収集ファイルのタスク名が「画面デザイン」である場合には、例えば、ＨＴＭＬ（HyperText Markup Language）ファイルを解析する。かかる解析によって、画面が持つ入力項目、画面に含まれるボタンや画面に挿入される画像などを分析することもできる。これら入力項目、ボタン及び画像が対応付けられることによって分析情報１３４ｂが生成される。その上で、構造ディクショナリ生成部１６３は、タスク別に解析内容が変更して得られる各種の分析情報１３４ｂを記憶部１３０へ登録する。

図１０は、分析情報１３４ｂの一例を示す図である。図１０には、アセンブリ情報である収集ファイルから分析された分析情報が図示されている。図１０に示す例で言えば、ファイル名「SCR0010Form.vb」のファイルのクラス名が「SCR0010FormClass」であり、５つのメソッド「InitForm」、「CheckParam」、「EntryInput」、「UpdateData」及び「SearchData」が含まれることを示している。さらに、メソッド「InitForm」は、他のクラス「DisplayForm」のメソッド「display」を呼出先クラスメソッドとしていることがわかる。同様に、他の４つのメソッドについても呼出先メソッドを特定することができる。加えて、ファイル名「SCR0010Form.vb」のファイルは、他のクラス「Display」、「Common」、「SCR0010Logic」及び「SCRCommonLogic」に依存していることもわかる。つまり、ファイル名「SCR0010Form.vb」のファイルに変更を行った場合には、アセンブリ情報の分析情報を参照することによって、他のクラス「Display」、「Common」、「SCR0010Logic」及び「SCRCommonLogic」に影響が及ぶことを特定できる。

このようにして構造ディクショナリ生成部１６３によってターゲット資産情報１３４ａ及び分析情報１３４ｂを含む構造ディクショナリ１３４が記憶部１３０へ登録されることになる。

エクスプローラ１７０は、構造ディクショナリ１３４を用いて、クライアント端末３０から指定される観点に合わせて開発資産を分類した上で開発資産の一覧を階層的に表示させるソフトウェア、すなわち「エクスプローラ」を実行する処理部である。

一態様としては、エクスプローラ１７０は、クライアント端末３０から表示ビューの指定を含む開発資産の閲覧要求を受け付ける。かかる表示ビューの一例としては、開発資産に含まれる開発成果物を工程を基準に分類して表示する「工程ビュー」や開発成果物を共通業務（機能）を基準に分類して表示する「共通業務ビュー」などが挙げられる。なお、開発プロジェクトの工程では、要件定義によって共通業務ごとに必要な機能が定義されることから共通業務および機能はほぼ等価であると言えるので、表示ビューの名称は「機能ビュー」としてもかまわない。

例えば、エクスプローラ１７０は、表示ビューとして「工程ビュー」が指定された場合に、工程ＩＤ、タスクＩＤ、機能ＩＤの順番で開発資産情報１３１に含まれる開発成果物をグルーピングする。具体的には、エクスプローラ１７０は、ターゲット資産情報１３４ａから開発成果物の工程ＩＤ、タスクＩＤ及び機能ＩＤを読み出す。その上で、エクスプローラ１７０は、開発成果物のうち工程ＩＤが共通する開発成果物同士を同一のディレクトリにグルーピングする。その後、エクスプローラ１７０は、工程ＩＤによって同一のディレクトリにグルーピングされた開発成果物を対象に、タスクＩＤが共通する開発成果物同士を上記の工程ＩＤによって分類されたディレクトリの配下に配置される同一のディレクトリにグルーピングする。さらに、エクスプローラ１７０は、タスクＩＤによって同一のディレクトリにグルーピングされた開発成果物を対象に、機能ＩＤが共通する開発成果物同士を上記のタスクＩＤによって分類されたディレクトリの配下に配置される同一のディレクトリにグルーピングする。その上で、エクスプローラ１７０は、工程ＩＤ、タスクＩＤ、機能ＩＤの順に階層化された開発資産の一覧画面をクライアント端末３０へ送信する。

かかる「工程ビュー」の開発資産の一覧画面において、ルートディレクトリの配下には、各工程「設計」、「レイアウト」、「製造」、「ビルド」や「参考」などに対応するディレクトリが配置される。さらに、各工程のディレクトリの配下には、各タスクに対応するディレクトリが配置される。例えば、工程「レイアウト」のディレクトリの配下には、「データセット」、「画面」や「帳票」などのタスクに関するディレクトリが配置される。さらに、各タスクのディレクトリの配下には、各機能に対応するディレクトリが配置される。さらに、各機能のディレクトリの配下には、機能に含まれる開発成果物のファイルが配置される。このように、上記の「工程ビュー」の一覧画面では、「工程＜タスク＜機能」といった階層構造によって開発資産の一覧が表示される。かかる「工程ビュー」は、例えば、開発関係者の中でも、アプリケーションを開発する開発ＳＥ（Systems Engineer）等の熟練者向きの表示ビューと言える。熟練者であれば、開発プロジェクトの工程の名称を始め、設計書のドキュメントの命名規約やソースコードのコーディング規約などの開発規約に精通しているので、工程、タスク、機能の順にディレクトリを簡単にたどることができる。したがって、目的の開発成果物にも容易にたどりつくことができる。

一方、エクスプローラ１７０は、表示ビューとして「共通業務ビュー」が指定された場合に、機能ＩＤ、工程ＩＤ、タスクＩＤの順番で開発資産情報１３１に含まれる開発成果物をグルーピングする。具体的には、エクスプローラ１７０は、ターゲット資産情報１３４ａから開発成果物の工程ＩＤ、タスクＩＤ及び機能ＩＤを読み出す。その上で、エクスプローラ１７０は、開発成果物のうち機能ＩＤが共通する開発成果物同士を同一のディレクトリにグルーピングする。その後、エクスプローラ１７０は、機能ＩＤによって同一のディレクトリにグルーピングされた開発成果物を対象に、工程ＩＤが共通する開発成果物同士を上記の機能ＩＤによって分類されたディレクトリの配下に配置される同一のディレクトリにグルーピングする。さらに、エクスプローラ１７０は、工程ＩＤによって同一のディレクトリにグルーピングされた開発成果物を対象に、タスクＩＤが共通する開発成果物同士を上記の工程ＩＤによって分類されたディレクトリの配下に配置される同一のディレクトリにグルーピングする。その上で、エクスプローラ１７０は、機能ＩＤ、工程ＩＤ、タスクＩＤの順に階層化された開発資産の一覧画面をクライアント端末３０へ送信する。

かかる「共通業務ビュー」の開発資産の一覧画面において、ルートディレクトリの配下には、各機能「受注入力機能」、「注文書作成機能」、「単価計算部品」や「商品検索ダイアログ」などに対応するディレクトリが配置される。さらに、各機能のディレクトリの配下には、各工程に対応するディレクトリが配置される。さらに、各工程のディレクトリの配下には、各タスクに対応するディレクトリが配置される。さらに、各タスクのディレクトリの配下には、タスクに含まれる開発成果物のファイルが配置される。このように、上記の「共通業務ビュー」の一覧画面では、「機能＜工程＜タスク」といった階層構造によって開発資産の一覧が表示される。かかる「共通業務ビュー」は、例えば、開発関係者の中でも、システムの運用や保守を手がけるフィールドＳＥ等の初心者向きの表示ビューと言える。なぜなら、開発規約に精通していなくとも、システムの運用や保守で問題や課題が生じた機能から順にディレクトリを簡単にたどることができるからである。したがって、目的の開発成果物にも容易にたどりつくことができる。

なお、ここでは、「工程ビュー」または「共通業務ビュー」が指定される場合を例示したが、開示の装置はこれに限定されるものではなく、開発資産に含まれる開発成果物をエンティティを基準に分類して表示する「エンティティビュー」などの他の表示ビューを指定させることとしてもよい。また、ここでは、工程ＩＤ、タスクＩＤ及び機能ＩＤを用いてグルーピングを実行する場合を例示したが、エンティティＩＤをさらに用いてグルーピングを実行することとしてもよく、工程ＩＤ、タスクＩＤまたは機能ＩＤのいずれかのＩＤによるグルーピングを省略してエンティティＩＤによるグルーピングを実行することとしてもかまわない。

また、エクスプローラ１７０は、クライアント端末３０からフィルタ条件を含む検索要求を受け付けた場合には、フィルタ条件に合致する開発成果物だけを検索結果として表示させることもできる。例えば、フィルタ条件の一例としては、機能名を設定させることができる。このように、機能名がフィルタ条件に設定されている場合には、エクスプローラ１７０は、ターゲット資産情報１３４ａから当該機能名に対応する機能ＩＤを含むファイル名を抽出する。その上で、エクスプローラ１７０は、先に抽出したファイル名の一覧を検索結果としてクライアント端末３０に表示させる。これによって、例えば、初心者は、開発規約等に精通していなくとも、目的の開発成果物を検索によって絞り込むことができる。

他のフィルタ条件の一例としては、エンティティ名を設定させることもできる。このように、エンティティ名がフィルタ条件に設定されている場合には、エクスプローラ１７０は、ターゲット資産情報１３４ａから当該エンティティ名に対応するエンティティＩＤを含むファイル名を抽出する。その上で、エクスプローラ１７０は、先に抽出したファイル名の一覧を検索結果としてクライアント端末３０に表示させる。これによって、開発関係者は、データベースのスキームや計算のロジックなどに変更があった場合に、変更があった開発成果物を検索によって絞り込むことができる。

更なるフィルタ条件の一例としては、メソッドを設定させることもできる。このように、メソッドがフィルタ条件に設定されている場合には、エクスプローラ１７０は、各種分析情報１３４ｂから当該メソッドに対応付けられたファイル名を抽出する。その上で、エクスプローラ１７０は、ターゲット資産情報１３４ａから当該ファイル名に対応付けられた機能ＩＤを抽出する。さらに、エクスプローラ１７０は、ターゲット資産情報１３４ａから当該機能ＩＤを含むファイル名を抽出する。その上で、エクスプローラ１７０は、先に抽出したファイル名の一覧を検索結果としてクライアント端末３０に表示させる。これによって、開発関係者は、フィルタ条件として指定されたクラス名のファイルに変更があった場合に、その影響が及ぶファイルに絞ってファイルを表示させることができる。

また、エクスプローラ１７０は、クライアント端末３０によってファイルが選択された場合に、エクスプローラ定義情報１３５を用いて、当該ファイルの起動操作の選択肢の他に、当該ファイルに関連する他のファイルの起動操作もしくは当該ファイルの再配置操作を操作の選択肢として表示させる。

図１１は、エクスプローラ定義情報１３５の一例を示す図である。図１１に示すように、エクスプローラ定義情報１３５の一態様としては、タスクＩＤ、タスク名、対象資産およびエクスプローラ定義が対応付けられたデータを採用できる。ここで言う「対象資産」とは、クライアント端末３０によって選択される開発資産のファイル名を指す。また、「エクスプローラ定義」とは、クライアント端末３０によって選択された対象資産が選択された場合に、エクスプローラ１７０がクライアント端末３０に表示させる操作の選択肢を指す。

図１１に示すように、ファイル名「画面ＵＩ設計書」のファイルが選択された場合には、画面ＵＩ設計書を表計算ソフトで起動させる操作の選択肢「開く」をクライアント端末３０に表示させるとともに、当該画面ＵＩ設計書の参照を前提にコーディングが実行される「Form（画面）」のソースコードをフォーム生成支援ツールで起動させる操作の選択肢「フォーム生成支援ツールを開く」をクライアント端末３０に表示させることが定義されている。また、ファイル名「アセンブリファイル」が選択された場合には、アセンブリファイルをソースコードエディタで起動させる操作の選択肢「開く」をクライアント端末３０に表示させるとともに、当該アセンブリファイルをＸＸＸＳｅｒｖｅｒの実行フォルダへコピーさせる操作の選択肢「Ｗｅｂ参照の更新」をクライアント端末３０に表示させることが定義されている。なお、以下では、ファイルが選択される操作の一例として、クライアント端末３０に表示された開発資産の一覧画面上で操作を希望するファイルに対し、マウスの右クリックがなされる場合を想定するが、キーボード等の他の入力デバイスよってファイルが選択されることとしてもかまわない。

例えば、クライアント端末３０に表示された開発資産の一覧画面上でファイル名「画面ＵＩ設計書」のファイルに対し、所定の操作、例えばマウスの右クリックがなされた場合には、クライアント端末３０から開発資産管理装置１００へ当該ファイル名を含む操作選択肢のリクエストが通知される。かかるリクエストが開発資産管理装置１００によって受け付けられた場合に、画面ＵＩ設計書を表計算ソフトで起動させる操作の選択肢「開く」とともに、当該画面ＵＩ設計書の参照を前提にコーディングが実行される「Form（画面）」のソースコードをフォーム生成支援ツールで起動させる操作の選択肢「フォーム生成支援ツールを開く」がクライアント端末３０へ返信される。この場合には、図１２に示す操作選択画面がクライアント端末３０に表示される。

図１２は、クライアント端末３０に表示される画面の一例を示す図である。図１２に示すように、画面ＵＩ設計書のファイルの周辺に、画面ＵＩ設計書を表計算ソフトで起動させる操作の選択肢「開く」および「Form（画面）」のソースコードをフォーム生成支援ツールで起動させる操作の選択肢「フォーム生成支援ツールを開く」を含むコマンドウィンドウが表示される。これによって、選択されたファイルを起動させるという基本操作を選択肢として提示しつつ、選択されたファイルの次の工程で作業されるファイルを起動させるというアプリケーションの開発作業に特有の応用操作を選択肢として提示できる。この結果、開発関係者は、１つの工程の作業が終わった場合にそれに関連する次の工程のファイルを探さずとも次の工程のファイルを起動できるので、開発関係者の作業効率を向上させることができる。

例えば、クライアント端末３０に表示された開発資産の一覧画面上でファイル名「アセンブリファイル」のファイルに対し、所定の操作、例えばマウスの右クリックがなされた場合には、クライアント端末３０から開発資産管理装置１００へ当該ファイル名を含む操作選択肢のリクエストが通知される。かかるリクエストが開発資産管理装置１００によって受け付けられた場合に、アセンブリファイルをソースコードエディタで起動させる操作の選択肢「開く」とともに、当該アセンブリファイルをＸＸＸＳｅｒｖｅｒの実行フォルダへコピーさせる操作の選択肢「Ｗｅｂ参照の更新」がクライアント端末３０へ返信される。この場合には、図１３に示す操作選択画面がクライアント端末３０に表示される。

図１３は、クライアント端末３０に表示される画面の一例を示す図である。図１３に示すように、アセンブリファイルの周辺に、アセンブリファイルをソースコードエディタで起動させる操作の選択肢「開く」およびアセンブリファイルをＸＸＸＳｅｒｖｅｒの実行フォルダへコピーさせる操作の選択肢「Ｗｅｂ参照の更新」を含むコマンドウィンドウが表示される。これによって、選択されたファイルを起動させるという基本操作を選択肢として提示しつつ、実行形式にビルドされたファイルをＷｅｂサーバ等の実行環境に配置させるというアプリケーションの開発作業に特有の応用操作を選択肢として提示できる。この結果、通常の操作、例えばドラッグ＆ドロップ等の操作によって実行環境にファイルを配置するよりも操作を簡略化できるので、開発関係者の作業効率を向上させることができる。

なお、ここでは、クライアント端末３０に表示された開発資産の一覧画面上でファイルの選択操作を受け付ける場合を例示したが、検索結果が表示される検索結果画面上でファイルの選択操作を受け付ける場合にも同様に適用できる。

ナビゲータ１８０は、クライアント端末３０によって開発の作業内容とともに当該作業を実施する開発成果物の機能またはファイル名を受け付けた場合に、ナビゲーション定義情報１３６を用いて、当該作業内容が他の開発成果物に影響を及ぼす影響範囲を表示させるソフトウェア、すなわち「ナビゲータ」を実行する処理部である。

図１４は、ナビゲーション定義情報１３６の一例を示す図である。図１４に示すように、ナビゲーション定義情報１３６の一態様としては、作業内容、実施内容および情報源が対応付けられたデータを採用できる。ここで言う「作業内容」とは、開発の作業のカテゴリを指す。また、「実施内容」とは、作業内容が実行された場合に成果として得られる開発成果物のタスクおよび資産種別を指す。また、情報源とは、作業内容が実行される場合に参照される開発成果物のタスクおよび資産種別を指す。

図１４に示すように、要件定義書が作成される場合には、作業内容を「要件定義書の作成」として、要件定義書を作成するためには、タスク「document」に分類される資産種別「システム基本仕様」、「業務フロー図」、「データフロー図」、「サブシステム関連図」、「外部インタフェース概要図」、「外部インタフェース一覧」及び「システム機能一覧」などの開発資産を成果物として作成する必要があり、これらの開発資産を作成する際には、タスク「document」に分類される資産種別「組織図」、「業務概要図」、「業務用語一覧」及び「システム要件整理表」などの開発資産が参照される事が定められている。

例えば、クライアント端末３０から開発の「作業内容」と、修正対象とする開発成果物の「機能名」または「機能ＩＤ」との入力を受け付けた場合を想定する。この場合には、ナビゲータ１８０は、ナビゲーション定義情報１３６のうち、当該入力を受け付けた作業内容に定義された開発成果物の一覧を取得する。例えば、作業内容として「要件定義書の作成」が受け付けられていた場合には、「システム基本仕様」、「業務フロー図」、「データフロー図」、「サブシステム関連図」、「外部インタフェース概要図」、「外部インタフェース一覧」及び「システム機能一覧」などの開発成果物が取得される。かかる成果物の一覧を取得後に、ナビゲータ１８０は、ターゲット資産情報１３４ａのうち、資産種別が先に取得した開発成果物の一覧のいずれかに該当し、かつ先に入力を受けた機能名または機能ＩＤに該当する開発成果物の一覧を取得する。このようにしてターゲット資産情報１３４ａから取得された開発成果物の一覧が修正の必要な開発資産となる。さらに、ナビゲータ１８０は、ナビゲーション定義情報１３６に含まれる情報源の参照資産のうち、先に取得された修正の必要な開発資産に対応付けられている開発成果物を抽出する。その上で、ナビゲータ１８０は、修正の必要な開発資産およびその修正時に参照が定められている参照資産をクライアント端末３０に表示させる。

また、クライアント端末３０から開発の「作業内容」と、修正対象とする開発成果物の「ファイル名」との入力を受け付けた場合を想定する。この場合には、ナビゲータ１８０は、ナビゲーション定義情報１３６のうち、当該入力を受け付けた「作業内容」に定義された開発成果物の一覧を取得する。続いて、ナビゲータ１８０は、ターゲット資産情報１３４ａのうち、当該入力を受け付けた「ファイル名」に該当するレコードの機能ＩＤを抽出する。その上で、ナビゲータ１８０は、ターゲット資産情報１３４ａのうち、資産種別が先に取得した開発成果物の一覧のいずれかに該当し、かつ機能ＩＤが先に抽出された機能ＩＤと同一である開発成果物の一覧を取得する。このようにしてターゲット資産情報１３４ａから取得された開発成果物の一覧が修正の必要な開発資産となる。さらに、ナビゲータ１８０は、ナビゲーション定義情報１３６に含まれる情報源の参照資産のうち、先に取得された修正の必要な開発資産に対応付けられている開発成果物を抽出する。その上で、ナビゲータ１８０は、修正の必要な開発資産およびその修正時に参照が定められている参照資産をクライアント端末３０に表示させる。

このため、開発関係者は、修正対象の資産種別の表示によって作業内容が他の開発成果物に影響を及ぼす影響範囲を把握できるとともに、情報源となる資産種別の表示によって作業内容を円滑に進めることが可能になる。

［処理の流れ］
続いて、本実施例に係る開発資産管理装置の処理の流れについて説明する。なお、ここでは、開発資産管理装置１００によって実行される各種の処理を（１）開発資産収集処理、（２）分類キー情報作成処理、（３）構造ディクショナリ生成処理、（４）開発支援処理の順に説明することとする。

（１）開発資産収集処理
図１５は、実施例１に係る開発資産収集処理の手順を示すフローチャートである。この開発資産収集処理は、クライアント端末３０によって開発資産情報１３１に含まれる開発成果物が更新された場合に処理が起動される。

図１５に示すように、収集部１６１は、記憶部１３０に記憶された収集設定情報１３２のうち当該更新が実行されたサブシステムに関する開発資産の収集設定を読み出す（ステップＳ１０１）。このとき、収集部１６１は、先に読み出した収集設定のうち「設計ディクショナリ」に関する収集設定に定義された開発資産の配置場所を参照して、「設計ディクショナリ」に関するファイルを優先して収集する。

続いて、分類キー情報作成部１６２は、「設計ディクショナリ」に関するファイルのうち所定の定義ファイルから、開発成果物を分類するキーとする分類キー情報を作成する「分類キー情報作成処理」を実行する（ステップＳ１０２）。

その後、収集部１６１は、「設計ディクショナリ」以外の収集設定の中から収集設定を１つ選択する（ステップＳ１０３）。そして、収集部１６１は、ステップＳ１０３で選択した収集設定に定義された開発資産の配置場所が示すディレクトリを選択する（ステップＳ１０４）。その上で、収集部１６１は、ステップＳ１０４で選択したディレクトリ内のファイルを収集する（ステップＳ１０５）。

そして、構造ディクショナリ生成部１６３は、ステップＳ１０５で収集されたタスク名「設計ディクショナリ」以外の他のタスク名の収集ファイルが収集設定に定義された管理対象条件を満たすか否かを判定する（ステップＳ１０６）。

ここで、収集ファイルが管理対象条件を満たす場合（ステップＳ１０６肯定）には、構造ディクショナリ生成部１６３は、分類キー情報１３３を用いて、ステップＳ１０５で収集されたファイルから、開発成果物を分類可能なインデックスを辞書化した構造ディクショナリを生成する「構造ディクショナリ生成処理」を実行する（ステップＳ１０７）。なお、収集ファイルが管理対象条件を満たさない場合（ステップＳ１０６否定）には、上記の「構造ディクショナリ生成処理」は実行せずに、ステップＳ１０８へ移行する。

そして、ステップＳ１０４で選択されたディレクトリ内の全ファイルを収集するまで（ステップＳ１０８否定）、上記のステップＳ１０５〜ステップＳ１０７の処理が繰り返し実行される。その後、ステップＳ１０４で選択されたディレクトリ内の全ファイルを収集すると（ステップＳ１０８肯定）、収集部１６１は、当該ディレクトリに配下のディレクトリが存在するか否かを判定する（ステップＳ１０９）。

このとき、配下のディレクトリが存在する場合（ステップＳ１０９肯定）には、収集部１６１によって配下のディレクトリが新たに選択され（ステップＳ１０４）、上記のステップＳ１０４〜ステップＳ１０８までの処理が繰り返し実行される。

一方、配下のディレクトリが存在しない場合（ステップＳ１０９否定）には、収集部１６１は、全ての収集設定について処理が終了したか否かを判定する（ステップＳ１１０）。

このとき、全ての収集設定について処理が終了していない場合（ステップＳ１１０否定）には、新たな収集設定が１つ選択され（ステップＳ１０３）、上記のステップＳ１０３〜ステップＳ１０９までの処理が繰り返し実行される。なお、全ての収集設定について処理が終了した場合（ステップＳ１１０肯定）には、処理を終了する。

（２）分類キー情報作成処理
図１６は、実施例１に係る分類キー情報作成処理の手順を示すフローチャートである。この分類キー情報作成処理は、図１５に示したステップＳ１０２に対応する処理であり、「設計ディクショナリ」に関するファイルが収集された場合に処理が起動される。

図１６に示すように、分類キー情報作成部１６２は、タスク名「設計ディクショナリ」の収集ファイルのファイル名と所定の定義ファイルのファイル名、例えば「機能一覧定義」、「ドメイン定義」、「エンティティ定義」や「メッセージ定義」等と比較する（ステップＳ２０１）。

このとき、収集ファイルのファイル名が定義ファイルのファイル名と一致する場合（ステップＳ２０２肯定）には、分類キー情報作成部１６２は、定義ファイルの種類に応じて分類キー情報１３３を作成した上で記憶部１３０へ登録する（ステップＳ２０３及びステップＳ２０４）。

一方、収集ファイルのファイル名が定義ファイルのファイル名と一致しない場合（ステップＳ２０２否定）には、分類キー情報の作成は実行せずに、ステップＳ２０５へ移行する。

そして、タスク名「設計ディクショナリ」に関する全ての収集ファイルについて処理が終了するまで（ステップＳ２０５否定）には、上記のステップＳ２０１〜ステップＳ２０４までの処理が繰り返し実行される。その後、タスク名「設計ディクショナリ」に関する全ての収集ファイルについて処理が終了した場合（ステップＳ２０５肯定）には、処理を終了する。

（３）構造ディクショナリ生成処理
図１７は、実施例１に係る構造ディクショナリ生成処理の手順を示すフローチャートである。この構造ディクショナリ生成処理は、図１５に示したステップＳ１０７に対応する処理であり、収集ファイルが管理対象条件を満たす場合（ステップＳ１０６肯定）に処理が起動される。

図１７に示すように、構造ディクショナリ生成部１６３は、当該収集ファイルのサブシステム情報を取得する（ステップＳ３０１）。続いて、構造ディクショナリ生成部１６３は、分類キー情報１３３を用いて、収集ファイルに採番されている各種ＩＤ、例えば工程ＩＤ、タスクＩＤ、機能ＩＤやエンティティＩＤなどを特定する（ステップＳ３０２）。

その後、構造ディクショナリ生成部１６３は、ステップＳ３０２で特定した各種ＩＤをグルーピングした上で収集ファイルに対応付けることによってターゲット資産情報１３４ａを生成する（ステップＳ３０３）。その上で、構造ディクショナリ生成部１６３は、ステップＳ３０３で生成されたターゲット資産情報１３４ａを記憶部１３０へ登録する（ステップＳ３０４）。

続いて、構造ディクショナリ生成部１６３は、当該収集ファイルの内容を解析することによって分析情報を生成する（ステップＳ３０５）。その後、構造ディクショナリ生成部１６３は、タスク別に解析内容が変更して得られる各種の分析情報１３４ｂを記憶部１３０へ登録し（ステップＳ３０６）、処理を終了する。

（４）開発支援処理
図１８は、実施例１に係る開発支援処理の手順を示すフローチャートである。この開発支援処理は、クライアント端末３０から表示ビューの指定を含む開発資産の閲覧要求を受け付けた場合に処理が起動される。

図１８に示すように、表示ビューの指定を受け付けると（ステップＳ４０１）、エクスプローラ１７０は、構造ディクショナリ情報１３４に含まれるターゲット資産情報１３４ａを参照して、ステップＳ４０１で受け付けた表示ビューに応じて開発資産情報１３１に含まれる開発成果物をグルーピングする（ステップＳ４０２）。例えば、「工程ビュー」が指定された場合には、工程ＩＤ、タスクＩＤ、機能ＩＤの順番で開発資産情報１３１に含まれる開発成果物がグルーピングされる。また、「共通業務ビュー」が指定された場合には、機能ＩＤ、工程ＩＤ、タスクＩＤの順番で開発資産情報１３１に含まれる開発成果物がグルーピングされる。

その後、エクスプローラ１７０は、ステップＳ４０３でグルーピングされることによって階層化された開発資産の一覧画面をクライアント端末３０に表示させる（ステップＳ４０３）。

そして、クライアント端末３０によってファイルが選択された場合（ステップＳ４０４）には、エクスプローラ１７０によって当該ファイルの起動操作の選択肢の他に、当該ファイルの次の工程に割り当てられたファイルの起動操作もしくは当該ファイルの再配置操作が操作の選択肢としてクライアント端末３０に表示される。

このとき、ファイルの起動操作が選択された場合（ステップＳ４０５肯定）には、エクスプローラ１７０は、当該ファイルを起動し（ステップＳ４０６）、処理を終了する。

また、次の工程に割り当てられたファイルを関連ツールで起動させる操作が選択された場合（ステップＳ４０７肯定）には、エクスプローラ１７０は、次の工程に割り当てられたファイルを関連ツールで起動させ（ステップＳ４０８）、処理を終了する。

また、ファイルの再配置操作が選択された場合（ステップＳ４０７否定）には、エクスプローラ１７０は、ファイルの再配置操作を実行し（ステップＳ４０９）、処理を終了する。

［実施例１の効果］
上述してきたように、本実施例に係る開発資産管理装置１００は、開発成果物の集合である開発資産を収集し、開発資産のうち機能定義ファイルから各開発成果物を分類するキー情報として前記開発資産の機能が辞書化された機能辞書を作成し、開発資産のうち機能定義ファイル以外の開発成果物を対象に、開発成果物の機能を機能辞書を用いて特定するとともに、開発作業の工程が辞書化された工程辞書を用いて開発成果物の工程を特定した上で、特定された開発成果物の機能及び工程が対応付けられた構造辞書を生成し、機能が指定された場合に構造辞書を参照し、各開発成果物を機能でグルーピングした上で同じ機能の開発成果物を工程でグルーピングした開発資産の階層構造を一覧表示させ、工程が指定された場合に構造辞書を参照し、各開発成果物を工程でグルーピングした上で同じ工程の開発成果物を機能でグルーピングした開発資産の階層構造を一覧表示させる。

このため、開発プロジェクトの工程の名称を始め、設計書のドキュメントの命名規約やソースコードのコーディング規約などの開発規約に精通している熟練者は、工程、機能の順にディレクトリを簡単にたどることができる。一方、開発規約に精通していない初心者も、システムの運用や保守で問題や課題が生じた機能から順にディレクトリを簡単にたどることができる。

したがって、本実施例に係る開発資産管理装置１００によれば、開発規約に熟練しているか否かを問わず、開発関係者が目的の開発成果物を容易に探索できる。

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、クローラ１６０、エクスプローラ１７０またはナビゲータ１８０のうち一部の機能部を開発資産管理装置１００の外部装置としてネットワーク経由で接続するようにしてもよい。また、クローラ１６０、エクスプローラ１７０またはナビゲータ１８０のうち一部の機能部を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記の開発資産管理装置１００の機能を実現するようにしてもよい。また、記憶部に記憶される開発資産情報１３１、収集設定情報１３２、分類キー情報１３３、構造ディクショナリ１３４、エクスプローラ定義情報１３５及びナビゲーション定義情報１３６の全部または一部を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記の開発資産管理装置１００の機能を実現するようにしてもかまわない。

［開発支援プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１９を用いて、上記の実施例と同様の機能を有する開発支援プログラムを実行するコンピュータの一例について説明する。

図１９は、実施例１及び実施例２に係る開発支援プログラムを実行するコンピュータの一例について説明するための図である。図１９に示すように、コンピュータ１０００は、操作部１１００ａと、スピーカ１１００ｂと、カメラ１１００ｃと、ディスプレイ１２００と、通信部１３００とを有する。さらに、このコンピュータ１０００は、ＣＰＵ１５００と、ＲＯＭ１６００と、ＨＤＤ１７００と、ＲＡＭ１８００とを有する。これら１１０〜１８００の各部はバス１４００を介して接続される。

ＨＤＤ１７００には、図１９に示すように、上記の実施例１で示したクローラ１６０、エクスプローラ１７０及びナビゲータ１８０と同様の機能を発揮する開発支援プログラム１７００ａが予め記憶される。この開発支援プログラム１７００ａについては、図１に示した各々のクローラ１６０、エクスプローラ１７０及びナビゲータ１８０の各構成要素と同様、適宜統合又は分離しても良い。すなわち、ＨＤＤ１７００に格納される各データは、常に全てのデータがＨＤＤ１７００に格納される必要はなく、処理に必要なデータのみがＨＤＤ１７００に格納されれば良い。

そして、ＣＰＵ１５００が、開発支援プログラム１７００ａをＨＤＤ１７００から読み出してＲＡＭ１８００に展開する。これによって、図１９に示すように、開発支援プログラム１７００ａは、開発支援プロセス１８００ａとして機能する。この開発支援プロセス１８００ａは、ＨＤＤ１７００から読み出した各種データを適宜ＲＡＭ１８００上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、開発支援プロセス１８００ａは、図１に示したクローラ１６０、エクスプローラ１７０及びナビゲータ１８０にて実行される処理、例えば図１５〜図１８に示す処理を含む。また、ＣＰＵ１５００上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５００上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。

なお、上記の開発支援プログラム１７００ａについては、必ずしも最初からＨＤＤ１７００やＲＯＭ１６００に記憶させておく必要はない。例えば、コンピュータ１０００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１０００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１０００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１０００がこれらから各プログラムを取得して実行するようにしてもよい。

１００ 開発資産管理装置
１１０ 通信Ｉ／Ｆ部
１３０ 記憶部
１３１ 開発資産情報
１３２ 収集設定情報
１３３ 分類キー情報
１３４ 構造ディクショナリ
１３４ａ ターゲット資産情報
１３４ｂ 分析情報
１３５ エクスプローラ定義情報
１３６ ナビゲーション定義情報
１５０ 制御部
１６０ クローラ
１６１ 収集部
１６２ 分類キー情報作成部
１６３ 構造ディクショナリ生成部
１７０ エクスプローラ
１８０ ナビゲータ

Claims (7)

1. アプリケーションの開発作業による成果として得られる開発成果物の集合である開発資産を収集する収集部と、
   前記収集部によって収集される開発資産のうち、前記開発資産の体系が機能によって定義された機能定義ファイルから各開発成果物を分類するキー情報として前記開発資産の機能が辞書化された機能辞書を作成する分類キー情報作成部と、
   前記収集部によって収集された開発資産のうち前記機能定義ファイル以外の開発成果物を対象に、当該開発成果物に割り当てられた機能を前記機能辞書を用いて特定するとともに、開発作業の工程が辞書化された工程辞書を記憶する辞書記憶部を用いて当該開発成果物が割り当てられた工程を特定した上で、特定された開発成果物の機能および工程を対応付けることによって前記開発資産の構造が辞書化された構造辞書を生成する構造ディクショナリ生成部と、
   前記機能の指定を受け付けた場合には、前記構造辞書を参照して、前記開発資産に含まれる各開発成果物を機能によってグルーピングした上で同一の機能にグルーピングされた開発成果物を前記工程によってグルーピングした開発資産の階層構造を一覧表示させ、前記工程の指定を受け付けた場合には、前記構造辞書を参照して、前記開発資産に含まれる各開発成果物を工程によってグルーピングした上で同一の工程にグルーピングされた開発成果物を前記機能によってグルーピングした開発資産の階層構造を一覧表示させるエクスプローラと
   を有することを特徴とする開発資産管理装置。
2. 前記エクスプローラは、
   前記開発資産の階層構造が表示された表示部上で開発成果物の選択を受け付けた場合に、前記開発成果物ごとに当該開発成果物を起動する操作と当該開発成果物の次の工程が割り当てられた開発成果物を起動する操作とが対応付けられた定義情報を参照し、前記選択を受け付けた開発成果物を起動する操作の選択肢および前記選択を受け付けた開発成果物の次の工程が割り当てられた開発成果物を起動する操作の選択肢を前記表示部に表示させることを特徴とする請求項１に記載の開発資産管理装置。
3. 前記エクスプローラは、
   前記開発資産の階層構造が表示された表示部上で開発成果物の選択を受け付けた場合に、前記開発成果物ごとに当該開発成果物を起動する操作と当該開発成果物を実行環境へ配置する操作とが対応付けられた定義情報を参照し、前記選択を受け付けた開発成果物を起動する操作の選択肢および前記選択を受け付けた開発成果物を実行環境へ配置する操作の選択肢を前記表示部に表示させることを特徴とする請求項１に記載の開発資産管理装置。
4. 前記開発作業の内容とともに当該開発作業を実施する開発成果物または開発成果物の機能を受け付けた場合に、当該開発作業が他の開発成果物に影響を及ぼす影響範囲を案内表示させるナビゲータをさらに有することを特徴とする請求項１、２または３に記載の開発資産管理装置。
5. 前記ナビゲータは、前記影響範囲とともに前記開発作業を実施する場合に情報源となる開発成果物をさらに案内表示させることを特徴とする請求項４に記載の開発資産管理装置。
6. コンピュータが、
   アプリケーションの開発作業による成果として得られる開発成果物の集合である開発資産を収集し、
   前記開発資産のうち、前記開発資産の体系が機能によって定義された機能定義ファイルから各開発成果物を分類するキー情報として前記開発資産の機能が辞書化された機能辞書を作成し、
   前記開発資産のうち前記機能定義ファイル以外の開発成果物を対象に、当該開発成果物に割り当てられた機能を前記機能辞書を用いて特定するとともに、開発作業の工程が辞書化された工程辞書を記憶する辞書記憶部を用いて当該開発成果物が割り当てられた工程を特定した上で、特定された開発成果物の機能および工程を対応付けることによって前記開発資産の構造が辞書化された構造辞書を生成し、
   前記機能の指定を受け付けた場合には、前記構造辞書を参照して、前記開発資産に含まれる各開発成果物を機能によってグルーピングした上で同一の機能にグルーピングされた開発成果物を前記工程によってグルーピングした開発資産の階層構造を一覧表示させ、前記工程の指定を受け付けた場合には、前記構造辞書を参照して、前記開発資産に含まれる各開発成果物を工程によってグルーピングした上で同一の工程にグルーピングされた開発成果物を前記機能によってグルーピングした開発資産の階層構造を一覧表示させる
   処理を実行することを特徴とする開発支援方法。
7. コンピュータに、
   アプリケーションの開発作業による成果として得られる開発成果物の集合である開発資産を収集し、
   前記開発資産のうち、前記開発資産の体系が機能によって定義された機能定義ファイルから各開発成果物を分類するキー情報として前記開発資産の機能が辞書化された機能辞書を作成し、
   前記開発資産のうち前記機能定義ファイル以外の開発成果物を対象に、当該開発成果物に割り当てられた機能を前記機能辞書を用いて特定するとともに、開発作業の工程が辞書化された工程辞書を記憶する辞書記憶部を用いて当該開発成果物が割り当てられた工程を特定した上で、特定された開発成果物の機能および工程を対応付けることによって前記開発資産の構造が辞書化された構造辞書を生成し、
   前記機能の指定を受け付けた場合には、前記構造辞書を参照して、前記開発資産に含まれる各開発成果物を機能によってグルーピングした上で同一の機能にグルーピングされた開発成果物を前記工程によってグルーピングした開発資産の階層構造を一覧表示させ、前記工程の指定を受け付けた場合には、前記構造辞書を参照して、前記開発資産に含まれる各開発成果物を工程によってグルーピングした上で同一の工程にグルーピングされた開発成果物を前記機能によってグルーピングした開発資産の階層構造を一覧表示させる
   処理を実行させることを特徴とする開発支援プログラム。

Images