以下に、本願の開示する開発資産管理装置、開発支援方法及び開発支援プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
[開発資産管理装置の構成]
図1は、実施例1に係る開発資産管理装置の機能的構成を示すブロック図である。図1に示す開発資産管理装置100は、アプリケーションの開発によって得られる開発成果物の集合である開発資産を管理するものである。とりわけ、開発資産管理装置100は、開発成果物を分類可能なインデックスを辞書化した構造ディクショナリを生成した上で、構造ディクショナリを用いてクライアント端末30から指定される観点に合わせて開発資産を分類した上で開発資産の一覧を階層的に表示させるアプリケーションの開発支援サービスを提供する。
かかる開発資産管理装置100の一態様としては、上記の開発支援サービスを提供するWebサーバとして実装することとしてもよいし、また、アウトソーシングによって上記の開発支援サービスを提供するクラウドとして実装することもできる。他の一態様としては、パッケージソフトウェアやオンラインソフトウェアとして提供される開発支援プログラムを所望のコンピュータにプリインストール又はインストールさせることによっても実装できる。
図1に示す開発資産管理装置100は、所望のネットワークを介して、クライアント端末30と相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット(Internet)、LAN(Local Area Network)やVPN(Virtual Private Network)などの任意の種類の通信網を採用できる。
クライアント端末30は、上記の開発支援サービスの提供を受けるコンピュータである。例えば、クライアント端末30は、アプリケーションの開発に携わる開発関係者によって使用される。かかるクライアント端末30の一態様としては、パーソナルコンピュータを始めとする固定端末の他、携帯電話機、PHS(Personal Handyphone System)やPDA(Personal Digital Assistants)などの移動体端末も採用できる。
図1に示すように、開発資産管理装置100は、通信I/F(interface)部110と、記憶部130と、制御部150とを有する。なお、開発資産管理装置100は、図1に示した機能部以外にも既知のサーバ装置が有する各種の機能部、例えば各種の入出力デバイスなどを有することとしてもかまわない。
通信I/F部110は、他の装置、例えばクライアント端末30との間で通信制御を行うインタフェースである。かかる通信I/F部110の一態様としては、LANカードなどのネットワークインタフェースカードを採用できる。例えば、通信I/F部110は、クライアント端末30から開発資産の閲覧要求を受け付けたり、開発資産の一覧画面をクライアント端末30に送信したりする。
記憶部130は、制御部150で実行されるOS(Operating System)や開発支援プログラムなどの各種プログラムを記憶する記憶デバイスである。記憶部130の一態様としては、フラッシュメモリなどの半導体メモリ素子、ハードディスク、光ディスクなどの記憶装置が挙げられる。また、記憶部130は、上記の種類の記憶装置に限定されるものではなく、RAM(Random Access Memory)、ROM(Read Only Memory)であってもよい。記憶部130は、制御部150で実行されるプログラムに用いられるデータの一例として、後述する開発資産情報131、収集設定情報132、分類キー情報133、構造ディクショナリ134、エクスプローラ定義情報135やナビゲーション定義情報136などを記憶する。
制御部150は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部150は、図1に示すように、クローラ160と、エクスプローラ170と、ナビゲータ180とを有する。
クローラ160は、開発成果物を分類可能なインデックスを辞書化した構造ディクショナリを生成するソフトウェア、すなわち「クローラ」を実行する処理部である。一態様としては、クローラ160は、アプリケーションの開発プロジェクトの「工程」やアプリケーションが実現する「機能」を始めとする複数の観点で開発成果物を分類できるように、開発成果物ごとに工程IDおよび機能IDなどの複数のインデックスが対応付けられた構造ディクショナリを生成する。クローラ160は、図1に示すように、収集部161と、分類キー情報作成部162と、構造ディクショナリ生成部163とを有する。
収集部161は、収集設定情報132にしたがって開発資産情報131に含まれる開発資産を収集する処理部である。一態様としては、収集部161は、クライアント端末30によって開発資産情報131に含まれる開発成果物が更新された場合に、記憶部130に記憶された収集設定情報132のうち当該更新が実行されたサブシステムに関する開発資産の収集設定を読み出す。ここで、収集部161は、先に読み出した収集設定のうちサブシステム全体の体系が定義された定義ファイルを含むタスクの収集設定、すなわち「設計ディクショナリ」に関する収集設定に定義された開発資産の配置場所、例えば開発成果物であるファイルが格納されたディレクトリの所在を示すパスを参照して、「設計ディクショナリ」に関するファイルを優先して収集する。その後、収集部161は、「設計ディクショナリ」以外の収集設定について収集が終了するまでファイルの収集を繰り返し実行する。なお、ここでは、開発成果物の更新が実行されたサブシステムに関する開発資産をリアルタイムに収集する場合を例示したが、一定期間、例えば1分間や1時間が経過することをトリガーとして開発資産の収集を開始することとしてもかまわない。
ここで、収集部161が収集する開発資産および収集部161が収集時に参照する収集設定について説明する。以下では、一例として、販売管理のサブシステムに関する開発資産が収集される場合を想定して説明を行う。
図2は、開発資産の階層構造を模式化した模式図であり、図3は、開発資産に含まれるファイルの一例を示す図である。図2及び図3には、一例として、サブシステム「販売管理(SalesManagement)」に関する開発資産が図示されている。図2に示すように、販売管理の開発資産は、「設計資産」、「ソースコード資産」及び「プロダクト資産」に分類される。このうち、「設計資産」は、「設計書」および「設計ディクショナリ」へさらに分類される。また、「ソースコード資産」は、「画面デザインコード」、「帳票デザインコード」、「自動生成コード」、「ロジックコード」および「カスタマイズコード」へさらに分類される。また、「プロダクト資産」は、「Webサービス」、「Webアプリケーション」および「スマートクライアント」へさらに分類される。
このうち、設計書には、図3に示すように、要件定義(RD:Requirements Definition)、ユーザインタフェース設計(UI:User Interface design)、システム構造設計(SS:System Structure design)、プログラム構造設計(PS:Program Structure design)などの各種の設計書が含まれる。かかる設計書のファイル例としては、「販売管理メニュー設計.xlsx」や「受注入力画面UI設計書.xls」などのドキュメントが挙げられる。また、設計ディクショナリには、図3に示すように、機能一覧定義、ドメイン定義やメッセージ定義などの定義情報が含まれる。かかる設計ディクショナリのファイル例としては、「機能一覧定義.xml」、「機能ドメイン定義.xml」および「メッセージ定義.xml」などが挙げられる。同様に、ソースコード資産やプロダクト資産についても、図3に示す各種のファイルが存在する。これらのファイルの集合が開発資産情報131として記憶部130に記憶されている。
図4は、収集設定情報132の構成例を示す図である。図4には、販売管理のサブシステムに関する開発資産の収集設定が図示されている。図4に示すように、収集設定情報132の一例としては、タスク名、分類、詳細分類、配置場所、管理対象条件および備考が対応付けられたデータを採用できる。ここで言う「管理対象条件」とは、開発資産のうち上記の構造ディクショナリとして管理させるファイルの条件を指し、例えば、ファイルの拡張子に関する条件、ファイル名に関する条件やその他の条件が設定される。なお、ここでは、収集設定情報132が記憶部130に予め登録されている場合を例示したが、収集の都度、外部装置から取得することとしてもかまわない。
例えば、図4の例で言えば、収集部161は、他のタスクに優先してタスク名「設計ディクショナリ」の収集を開始する。すなわち、収集部161は、相対パス「\subsys\dic」が示すディレクトリの配下に全てのファイルを収集する。このとき、収集部161は、相対パス「\subsys\dic」が示すディレクトリ内にあるファイルだけでなく、当該ディレクトリよりも下位にある全てのディレクトリ内のファイルを収集する。その後、収集部161は、タスク名「設計ディクショナリ」以外のタスクに関する収集を開始する。例えば、開発資産のうちタスク名「設計文書」に関する開発成果物を収集する場合には、収集部161は、相対パス「\subsys\doc」が示すディレクトリの配下に全てのファイルを収集する。このとき、収集部161は、相対パス「\subsys\doc」が示すディレクトリ内にあるファイルだけでなく、当該ディレクトリよりも下位にある全てのディレクトリ内のファイルを収集する。このようにして全てのタスクに関する開発資産の収集が図4に示す収集設定にしたがって実行される。なお、図4の例では、配置場所として相対パスを例示したが、絶対パスで表現された配置場所を参照することとしてもかまわない。
分類キー情報作成部162は、収集部161によって収集されたファイルのうち所定の定義ファイルから、開発成果物を分類するキーとする分類キー情報を作成する処理部である。
一態様としては、分類キー情報作成部162は、収集部161によって収集されたタスク名「設計ディクショナリ」の収集ファイルのファイル名と所定の定義ファイルのファイル名とが一致するか否かを判定する。かかる定義ファイルとは、サブシステム全体の体系が定義された定義情報であり、例えば、「機能一覧定義」、「ドメイン定義」、「エンティティ定義」や「メッセージ定義」などが挙げられる。このとき、両者のファイル名は、必ずしも完全一致する必要はなく、前方一致または後方一致などの部分一致であれば定義ファイルと判別することとしてもよく、定義ファイルのファイル名の正規表現と比較することとしてもよい。ここで、分類キー情報作成部162は、収集ファイルのファイル名が定義ファイルのファイル名と一致する場合には、定義ファイルの種類に応じて分類キー情報133を作成した上で記憶部130へ登録する。一方、分類キー情報作成部162は、収集ファイルのファイル名が定義ファイルのファイル名と一致しない場合には、分類キー情報の作成は実行されない。そして、分類キー情報作成部162は、収集部161によって収集されたタスク名「設計ディクショナリ」に関する全ての収集ファイルを対象に、上記の分類キー情報の作成を実行する。
図5及び図6は、分類キー情報の一例を示す図である。図5には、サブシステム「販売管理」が有する機能が定義された機能一覧定義ファイルから作成された分類キー情報の一例を図示している。図6には、サブシステム「販売管理」が有するエンティティが定義されたエンティティ定義ファイルから作成された分類キー情報の一例が図示されている。
図5に示すように、収集ファイルが機能一覧定義ファイルである場合には、機能を識別する「機能ID(identification)」を始め、機能の名称を表す「機能名」および機能の種別を表す「機能種別」が対応付けられた情報が分類キー情報として作成される。例えば、機能一覧定義ファイルがXML(Extensible Markup Language)で記述されているとしたとき、定義ファイルに含まれるタグ「機能ID」、「機能名」及び「機能種別」が検索される。このとき、タグ「機能ID」、「機能名」及び「機能種別」に記述された値として、例えば、「SCR0010」、「受注入力機能」及び「画面」が抽出された場合には、「SCR0010」、「受注入力機能」及び「画面」が対応付けられた情報が分類キー情報として作成される。以降、同様に、図5に示す分類キー情報が作成される。図6に示すように、エンティティ定義ファイルである場合には、エンティティを識別する「エンティティID」とエンティティの名称を表す「エンティティ名」とが対応付けられた情報が分類キー情報として作成される。例えば、エンティティ定義ファイルがXMLで記述されているとしたとき、定義ファイルに含まれるタグ「エンティティID」及び「エンティティ名」が検索される。このとき、タグ「エンティティID」及び「エンティティ名」に記述された値として、例えば、「JyuchuTBL」及び「受注ジャーナルテーブル」が抽出された場合には、「JyuchuTBL」及び「受注ジャーナルテーブル」が対応付けられた情報が分類キー情報として作成される。以降、同様に、図6に示す分類キー情報が作成される。なお、ここでは、分類キー情報としてID以外にも名前や種別を抽出する場合を例示したが、必ずしも全てを抽出する必要はなく、例えば、定義ファイルごとにIDだけを抽出するようにしてもよい。
なお、図5及び図6の例では、機能一覧定義ファイルから作成された分類キー情報およびエンティティ定義ファイルから作成された分類キー情報を例示したが、分類キー情報は図5及び図6のものに限定されない。すなわち、詳細は図8を用いて後述するが、図5及び図6に示す分類キー情報の他にも、タスクIDおよび工程IDが対応付けられたタスク情報が分類キー情報としてあらかじめ登録されている。
構造ディクショナリ生成部163は、分類キー情報133を用いて、収集部161によって収集されたファイルから、開発成果物を分類可能なインデックスを辞書化した「構造ディクショナリ」を生成する処理部である。
一態様としては、構造ディクショナリ生成部163は、収集部161によって収集されたタスク名「設計ディクショナリ」以外の他のタスク名の収集ファイルが収集設定に定義された管理対象条件を満たすか否かを判定する。例えば、図4の例で言えば、タスク名「設計文書」に関する収集設定にしたがって開発成果物を収集している場合には、拡張子が「xls,Xlsx」であることが条件として定義されるとともに文章タイトルが「XXX」であることが定義されている。この場合には、構造ディクショナリ生成部163は、収集ファイルの拡張子が「xls,Xlsx」であり、かつ収集ファイルのプロパティに記述された文書タイトルが「XXX」であるか否かを判定する。このとき、収集ファイルの拡張子が「xls,Xlsx」であり、かつ収集ファイルのプロパティに記述された文書タイトルが「XXX」である場合に、当該収集ファイルが管理対象条件を満たすと判定される。また、タスク名「帳票」に関する収集設定にしたがって開発成果物を収集している場合には、拡張子が「rdl」であることが条件として定義されるとともにファイル名が「帳票定義」であることが定義されている。この場合には、構造ディクショナリ生成部163は、収集ファイルの拡張子が「rdl」であり、かつ収集ファイルのファイル名が「帳票定義」であるか否かを判定する。このとき、収集ファイルの拡張子が「rdl」であり、かつ収集ファイルのファイル名が「帳票定義」である場合に、当該収集ファイルが管理対象条件を満たすと判定される。この他の収集設定についても、図4に示した管理対象条件を満たすか否かが同様に判定される。
そして、構造ディクショナリ生成部163は、収集ファイルが管理対象条件を満たす場合に、当該収集ファイルのサブシステム情報を取得する。かかるサブシステム情報の一例としては、開発成果物の更新が実行されたサブシステム、すなわち開発資産の収集が実行されたサブシステムのサブシステムIDやサブシステム名が自動的に取得される。図7は、サブシステム情報の一例を示す図である。図7に示すように、開発資産管理装置100が管理する開発資産には、基盤「Framework」、共通「SystemFrame」、会計「GeneralLedger」、手形「Bill」、人事給与「SalaryCalculation」や販売管理「SalesManagement」などが含まれる。このうち、開発資産の収集が実行されているサブシステムは、販売管理であるので、サブシステムID「SalesManagement」及びサブシステム名「販売管理」がサブシステム情報として取得される。
続いて、構造ディクショナリ生成部163は、分類キー情報133を用いて、収集ファイルに採番されている各種ID、例えば工程ID、タスクID、機能IDやエンティティIDなどを特定する。
これを具体的に説明すると、構造ディクショナリ生成部163は、分類キー情報133の一例としてタスク情報のマスタテーブルを参照して、収集ファイルのタスクIDおよび工程IDを特定する。図8は、タスク情報の一例を示す図である。図8に示すタスク情報の一態様としては、タスクを識別する「タスクID」、タスクの名称を表す「タスク名」及び工程を識別する「工程ID」が対応付けられた情報を採用できる。かかるタスク情報のマスタテーブルに設けられたフィールドのうちタスク名は、図4に示した収集設定のフィールド「詳細分類」に対応する。例えば、図4に示した収集設定のうちタスク名「設計文書」に関する収集設定にしたがって開発成果物を収集している場合には、当該収集設定の詳細分類「設計文書」に対応するタスクIDおよび工程IDが図8に示すタスク情報のマスタテーブルから検索される。このとき、図8に示すように、収集が実行中である収集設定に定義された詳細分類「設計文書」がタスク情報のマスタテーブルのレコードのうち上から1番目のレコードのタスク名「設計文書」と一致する。この場合には、当該1番目のレコードのタスクID「document」及び工程ID「design」が取得されることになる。
これらタスクID及び工程IDの他、構造ディクショナリ生成部163は、図5に示した機能一覧定義ファイルから作成された分類キー情報を用いて、収集ファイルの機能IDを特定したり、図6に示したエンティティ定義ファイルから作成された分類キー情報を用いて、収集ファイルのエンティティIDを特定したりする。
例えば、機能IDを特定する場合には、構造ディクショナリ生成部163は、収集ファイルに含まれる文字列と、図5に示した分類キー情報に含まれる機能ID及び機能名との間でパターンマッチングを実行する。このとき、機能ID「SCR0010」または機能名「受注入力機能」と一致する文字列が収集ファイルに含まれる場合には、構造ディクショナリ生成部163は、当該収集ファイルの機能IDが「SCR0010」であると特定する。また、機能ID「CHU0020」または機能名「注文書類作成機能」と一致する文字列が収集ファイルに含まれる場合には、当該収集ファイルの機能IDが機能ID「CHU0020」であると特定する。なお、1つの収集ファイルに複数の機能IDや機能名が含まれる場合には、複数の機能IDを抽出すればよい。
また、エンティティIDを特定する場合には、構造ディクショナリ生成部163は、収集ファイルに含まれる文字列と、図6に示した分類キー情報に含まれるエンティティID及びエンティティ名との間でパターンマッチングを実行する。このとき、エンティティID「JyuchuTBL」またはエンティティ名「受注ジャーナルテーブル」と一致する文字列が収集ファイルに含まれる場合には、構造ディクショナリ生成部163は、当該収集ファイルのエンティティIDが「JyuchuTBL」であると特定する。また、エンティティID「ShohinMST」またはエンティティ名「商品マスタテーブル」と一致する文字列が収集ファイルに含まれる場合には、当該収集ファイルのエンティティIDがエンティティID「ShohinMST」であると特定する。なお、1つの収集ファイルに複数のエンティティIDやエンティティ名が含まれる場合には、複数のエンティティIDを抽出すればよい。
なお、ここでは、収集ファイルに含まれる文字列と、図5及び図6に示したIDや名称との間でパターンマッチングを実行することによって機能IDやエンティティIDを特定する場合を例示したが、機能IDやエンティティIDの特定方法はこれに限定されない。例えば、収集ファイルのフォーマットで機能IDやエンティティIDが記述される箇所が予め固定的に定められている場合には、パターンマッチングを実行せずとも、フォーマットで定められた箇所を参照することによって機能IDやエンティティIDを取得することとしてもよい。
このように、収集ファイルの各種IDが特定されると、構造ディクショナリ生成部163は、先に特定した各種IDを収集ファイルに対応付けることによってターゲット資産情報134aを生成する。例えば、構造ディクショナリ生成部163は、当該収集ファイルの配置場所である資産相対パス、収集ファイルのファイル名、収集ファイルの拡張子、収集ファイルの資産種別、収集ファイルが属するサブシステム、機能ID、エンティティID及びタスクIDを対応付けたターゲット資産情報134aを生成する。その上で、構造ディクショナリ生成部163は、先に生成されたターゲット資産情報134aを記憶部130へ登録する。なお、ここでは、タスク情報のマスタテーブルを用いて、タスクIDから工程IDを抽出できるので、工程IDの登録を省略しているが、工程IDをさらに対応付けてターゲット資産情報を生成した上で記憶部130へ登録することもできる。
図9は、ターゲット資産情報134aの一例を示す図である。図9には、販売管理のサブシステムに関する開発資産から生成されたターゲット資産情報134aを図示している。例えば、図9に示す上から1番目のレコードは、ファイル名「受注入力画面設計書.xls」の収集ファイルが資産相対パス「\subsys\doc\」に配置されており、当該受注入力画面設計書.xlsの機能IDが「SCR0010」であり、エンティティIDが「JuchuTBL」及び「ChumonTBL」であり、かつタスクIDが「document」であることを示す。また、図8に示したタスク情報のマスタテーブルには、タスクID「document」と工程ID「design」が対応付けられているので、当該収集ファイルは工程ID「design」とさらに対応付けられているとも言える。このように、ターゲット資産情報134aには、ファイル名と各種IDとが対応付けられているので、ファイルを機能によって分類することもできるし、エンティティによって分類することもできるし、タスクによって分類することもできるし、工程によって分類することもできる。
かかるターゲット資産情報134aの登録後に、構造ディクショナリ生成部163は、当該収集ファイルの内容を解析することによって分析情報を生成する。ここで、解析内容は、収集ファイルのタスクに応じて変更される。例えば、収集ファイルのタスク名が「アセンブリ情報」である場合には、DLL(Dynamic Link Library)ファイルやEXEファイルを逆アセンブルで解析する。かかる逆アセンブルによって、例えば、収集ファイルのクラスを解析したり、クラスに含まれるメソッドを解析したり、メソッドの中でどのようなクラスのメソッドを呼び出しているのかを呼出先クラスメソッドとして解析したり、さらには、呼び出すメソッドがどのクラスに依存しているのかを依存クラスとして解析したりすることができる。これらクラス、メソッド、呼出先クラスメソッド及び依存クラスがファイル名に対応付けられることによって分析情報134bが生成される。また、収集ファイルのタスク名が「画面デザイン」である場合には、例えば、HTML(HyperText Markup Language)ファイルを解析する。かかる解析によって、画面が持つ入力項目、画面に含まれるボタンや画面に挿入される画像などを分析することもできる。これら入力項目、ボタン及び画像が対応付けられることによって分析情報134bが生成される。その上で、構造ディクショナリ生成部163は、タスク別に解析内容が変更して得られる各種の分析情報134bを記憶部130へ登録する。
図10は、分析情報134bの一例を示す図である。図10には、アセンブリ情報である収集ファイルから分析された分析情報が図示されている。図10に示す例で言えば、ファイル名「SCR0010Form.vb」のファイルのクラス名が「SCR0010FormClass」であり、5つのメソッド「InitForm」、「CheckParam」、「EntryInput」、「UpdateData」及び「SearchData」が含まれることを示している。さらに、メソッド「InitForm」は、他のクラス「DisplayForm」のメソッド「display」を呼出先クラスメソッドとしていることがわかる。同様に、他の4つのメソッドについても呼出先メソッドを特定することができる。加えて、ファイル名「SCR0010Form.vb」のファイルは、他のクラス「Display」、「Common」、「SCR0010Logic」及び「SCRCommonLogic」に依存していることもわかる。つまり、ファイル名「SCR0010Form.vb」のファイルに変更を行った場合には、アセンブリ情報の分析情報を参照することによって、他のクラス「Display」、「Common」、「SCR0010Logic」及び「SCRCommonLogic」に影響が及ぶことを特定できる。
このようにして構造ディクショナリ生成部163によってターゲット資産情報134a及び分析情報134bを含む構造ディクショナリ134が記憶部130へ登録されることになる。
エクスプローラ170は、構造ディクショナリ134を用いて、クライアント端末30から指定される観点に合わせて開発資産を分類した上で開発資産の一覧を階層的に表示させるソフトウェア、すなわち「エクスプローラ」を実行する処理部である。
一態様としては、エクスプローラ170は、クライアント端末30から表示ビューの指定を含む開発資産の閲覧要求を受け付ける。かかる表示ビューの一例としては、開発資産に含まれる開発成果物を工程を基準に分類して表示する「工程ビュー」や開発成果物を共通業務(機能)を基準に分類して表示する「共通業務ビュー」などが挙げられる。なお、開発プロジェクトの工程では、要件定義によって共通業務ごとに必要な機能が定義されることから共通業務および機能はほぼ等価であると言えるので、表示ビューの名称は「機能ビュー」としてもかまわない。
例えば、エクスプローラ170は、表示ビューとして「工程ビュー」が指定された場合に、工程ID、タスクID、機能IDの順番で開発資産情報131に含まれる開発成果物をグルーピングする。具体的には、エクスプローラ170は、ターゲット資産情報134aから開発成果物の工程ID、タスクID及び機能IDを読み出す。その上で、エクスプローラ170は、開発成果物のうち工程IDが共通する開発成果物同士を同一のディレクトリにグルーピングする。その後、エクスプローラ170は、工程IDによって同一のディレクトリにグルーピングされた開発成果物を対象に、タスクIDが共通する開発成果物同士を上記の工程IDによって分類されたディレクトリの配下に配置される同一のディレクトリにグルーピングする。さらに、エクスプローラ170は、タスクIDによって同一のディレクトリにグルーピングされた開発成果物を対象に、機能IDが共通する開発成果物同士を上記のタスクIDによって分類されたディレクトリの配下に配置される同一のディレクトリにグルーピングする。その上で、エクスプローラ170は、工程ID、タスクID、機能IDの順に階層化された開発資産の一覧画面をクライアント端末30へ送信する。
かかる「工程ビュー」の開発資産の一覧画面において、ルートディレクトリの配下には、各工程「設計」、「レイアウト」、「製造」、「ビルド」や「参考」などに対応するディレクトリが配置される。さらに、各工程のディレクトリの配下には、各タスクに対応するディレクトリが配置される。例えば、工程「レイアウト」のディレクトリの配下には、「データセット」、「画面」や「帳票」などのタスクに関するディレクトリが配置される。さらに、各タスクのディレクトリの配下には、各機能に対応するディレクトリが配置される。さらに、各機能のディレクトリの配下には、機能に含まれる開発成果物のファイルが配置される。このように、上記の「工程ビュー」の一覧画面では、「工程<タスク<機能」といった階層構造によって開発資産の一覧が表示される。かかる「工程ビュー」は、例えば、開発関係者の中でも、アプリケーションを開発する開発SE(Systems Engineer)等の熟練者向きの表示ビューと言える。熟練者であれば、開発プロジェクトの工程の名称を始め、設計書のドキュメントの命名規約やソースコードのコーディング規約などの開発規約に精通しているので、工程、タスク、機能の順にディレクトリを簡単にたどることができる。したがって、目的の開発成果物にも容易にたどりつくことができる。
一方、エクスプローラ170は、表示ビューとして「共通業務ビュー」が指定された場合に、機能ID、工程ID、タスクIDの順番で開発資産情報131に含まれる開発成果物をグルーピングする。具体的には、エクスプローラ170は、ターゲット資産情報134aから開発成果物の工程ID、タスクID及び機能IDを読み出す。その上で、エクスプローラ170は、開発成果物のうち機能IDが共通する開発成果物同士を同一のディレクトリにグルーピングする。その後、エクスプローラ170は、機能IDによって同一のディレクトリにグルーピングされた開発成果物を対象に、工程IDが共通する開発成果物同士を上記の機能IDによって分類されたディレクトリの配下に配置される同一のディレクトリにグルーピングする。さらに、エクスプローラ170は、工程IDによって同一のディレクトリにグルーピングされた開発成果物を対象に、タスクIDが共通する開発成果物同士を上記の工程IDによって分類されたディレクトリの配下に配置される同一のディレクトリにグルーピングする。その上で、エクスプローラ170は、機能ID、工程ID、タスクIDの順に階層化された開発資産の一覧画面をクライアント端末30へ送信する。
かかる「共通業務ビュー」の開発資産の一覧画面において、ルートディレクトリの配下には、各機能「受注入力機能」、「注文書作成機能」、「単価計算部品」や「商品検索ダイアログ」などに対応するディレクトリが配置される。さらに、各機能のディレクトリの配下には、各工程に対応するディレクトリが配置される。さらに、各工程のディレクトリの配下には、各タスクに対応するディレクトリが配置される。さらに、各タスクのディレクトリの配下には、タスクに含まれる開発成果物のファイルが配置される。このように、上記の「共通業務ビュー」の一覧画面では、「機能<工程<タスク」といった階層構造によって開発資産の一覧が表示される。かかる「共通業務ビュー」は、例えば、開発関係者の中でも、システムの運用や保守を手がけるフィールドSE等の初心者向きの表示ビューと言える。なぜなら、開発規約に精通していなくとも、システムの運用や保守で問題や課題が生じた機能から順にディレクトリを簡単にたどることができるからである。したがって、目的の開発成果物にも容易にたどりつくことができる。
なお、ここでは、「工程ビュー」または「共通業務ビュー」が指定される場合を例示したが、開示の装置はこれに限定されるものではなく、開発資産に含まれる開発成果物をエンティティを基準に分類して表示する「エンティティビュー」などの他の表示ビューを指定させることとしてもよい。また、ここでは、工程ID、タスクID及び機能IDを用いてグルーピングを実行する場合を例示したが、エンティティIDをさらに用いてグルーピングを実行することとしてもよく、工程ID、タスクIDまたは機能IDのいずれかのIDによるグルーピングを省略してエンティティIDによるグルーピングを実行することとしてもかまわない。
また、エクスプローラ170は、クライアント端末30からフィルタ条件を含む検索要求を受け付けた場合には、フィルタ条件に合致する開発成果物だけを検索結果として表示させることもできる。例えば、フィルタ条件の一例としては、機能名を設定させることができる。このように、機能名がフィルタ条件に設定されている場合には、エクスプローラ170は、ターゲット資産情報134aから当該機能名に対応する機能IDを含むファイル名を抽出する。その上で、エクスプローラ170は、先に抽出したファイル名の一覧を検索結果としてクライアント端末30に表示させる。これによって、例えば、初心者は、開発規約等に精通していなくとも、目的の開発成果物を検索によって絞り込むことができる。
他のフィルタ条件の一例としては、エンティティ名を設定させることもできる。このように、エンティティ名がフィルタ条件に設定されている場合には、エクスプローラ170は、ターゲット資産情報134aから当該エンティティ名に対応するエンティティIDを含むファイル名を抽出する。その上で、エクスプローラ170は、先に抽出したファイル名の一覧を検索結果としてクライアント端末30に表示させる。これによって、開発関係者は、データベースのスキームや計算のロジックなどに変更があった場合に、変更があった開発成果物を検索によって絞り込むことができる。
更なるフィルタ条件の一例としては、メソッドを設定させることもできる。このように、メソッドがフィルタ条件に設定されている場合には、エクスプローラ170は、各種分析情報134bから当該メソッドに対応付けられたファイル名を抽出する。その上で、エクスプローラ170は、ターゲット資産情報134aから当該ファイル名に対応付けられた機能IDを抽出する。さらに、エクスプローラ170は、ターゲット資産情報134aから当該機能IDを含むファイル名を抽出する。その上で、エクスプローラ170は、先に抽出したファイル名の一覧を検索結果としてクライアント端末30に表示させる。これによって、開発関係者は、フィルタ条件として指定されたクラス名のファイルに変更があった場合に、その影響が及ぶファイルに絞ってファイルを表示させることができる。
また、エクスプローラ170は、クライアント端末30によってファイルが選択された場合に、エクスプローラ定義情報135を用いて、当該ファイルの起動操作の選択肢の他に、当該ファイルに関連する他のファイルの起動操作もしくは当該ファイルの再配置操作を操作の選択肢として表示させる。
図11は、エクスプローラ定義情報135の一例を示す図である。図11に示すように、エクスプローラ定義情報135の一態様としては、タスクID、タスク名、対象資産およびエクスプローラ定義が対応付けられたデータを採用できる。ここで言う「対象資産」とは、クライアント端末30によって選択される開発資産のファイル名を指す。また、「エクスプローラ定義」とは、クライアント端末30によって選択された対象資産が選択された場合に、エクスプローラ170がクライアント端末30に表示させる操作の選択肢を指す。
図11に示すように、ファイル名「画面UI設計書」のファイルが選択された場合には、画面UI設計書を表計算ソフトで起動させる操作の選択肢「開く」をクライアント端末30に表示させるとともに、当該画面UI設計書の参照を前提にコーディングが実行される「Form(画面)」のソースコードをフォーム生成支援ツールで起動させる操作の選択肢「フォーム生成支援ツールを開く」をクライアント端末30に表示させることが定義されている。また、ファイル名「アセンブリファイル」が選択された場合には、アセンブリファイルをソースコードエディタで起動させる操作の選択肢「開く」をクライアント端末30に表示させるとともに、当該アセンブリファイルをXXXServerの実行フォルダへコピーさせる操作の選択肢「Web参照の更新」をクライアント端末30に表示させることが定義されている。なお、以下では、ファイルが選択される操作の一例として、クライアント端末30に表示された開発資産の一覧画面上で操作を希望するファイルに対し、マウスの右クリックがなされる場合を想定するが、キーボード等の他の入力デバイスよってファイルが選択されることとしてもかまわない。
例えば、クライアント端末30に表示された開発資産の一覧画面上でファイル名「画面UI設計書」のファイルに対し、所定の操作、例えばマウスの右クリックがなされた場合には、クライアント端末30から開発資産管理装置100へ当該ファイル名を含む操作選択肢のリクエストが通知される。かかるリクエストが開発資産管理装置100によって受け付けられた場合に、画面UI設計書を表計算ソフトで起動させる操作の選択肢「開く」とともに、当該画面UI設計書の参照を前提にコーディングが実行される「Form(画面)」のソースコードをフォーム生成支援ツールで起動させる操作の選択肢「フォーム生成支援ツールを開く」がクライアント端末30へ返信される。この場合には、図12に示す操作選択画面がクライアント端末30に表示される。
図12は、クライアント端末30に表示される画面の一例を示す図である。図12に示すように、画面UI設計書のファイルの周辺に、画面UI設計書を表計算ソフトで起動させる操作の選択肢「開く」および「Form(画面)」のソースコードをフォーム生成支援ツールで起動させる操作の選択肢「フォーム生成支援ツールを開く」を含むコマンドウィンドウが表示される。これによって、選択されたファイルを起動させるという基本操作を選択肢として提示しつつ、選択されたファイルの次の工程で作業されるファイルを起動させるというアプリケーションの開発作業に特有の応用操作を選択肢として提示できる。この結果、開発関係者は、1つの工程の作業が終わった場合にそれに関連する次の工程のファイルを探さずとも次の工程のファイルを起動できるので、開発関係者の作業効率を向上させることができる。
例えば、クライアント端末30に表示された開発資産の一覧画面上でファイル名「アセンブリファイル」のファイルに対し、所定の操作、例えばマウスの右クリックがなされた場合には、クライアント端末30から開発資産管理装置100へ当該ファイル名を含む操作選択肢のリクエストが通知される。かかるリクエストが開発資産管理装置100によって受け付けられた場合に、アセンブリファイルをソースコードエディタで起動させる操作の選択肢「開く」とともに、当該アセンブリファイルをXXXServerの実行フォルダへコピーさせる操作の選択肢「Web参照の更新」がクライアント端末30へ返信される。この場合には、図13に示す操作選択画面がクライアント端末30に表示される。
図13は、クライアント端末30に表示される画面の一例を示す図である。図13に示すように、アセンブリファイルの周辺に、アセンブリファイルをソースコードエディタで起動させる操作の選択肢「開く」およびアセンブリファイルをXXXServerの実行フォルダへコピーさせる操作の選択肢「Web参照の更新」を含むコマンドウィンドウが表示される。これによって、選択されたファイルを起動させるという基本操作を選択肢として提示しつつ、実行形式にビルドされたファイルをWebサーバ等の実行環境に配置させるというアプリケーションの開発作業に特有の応用操作を選択肢として提示できる。この結果、通常の操作、例えばドラッグ&ドロップ等の操作によって実行環境にファイルを配置するよりも操作を簡略化できるので、開発関係者の作業効率を向上させることができる。
なお、ここでは、クライアント端末30に表示された開発資産の一覧画面上でファイルの選択操作を受け付ける場合を例示したが、検索結果が表示される検索結果画面上でファイルの選択操作を受け付ける場合にも同様に適用できる。
ナビゲータ180は、クライアント端末30によって開発の作業内容とともに当該作業を実施する開発成果物の機能またはファイル名を受け付けた場合に、ナビゲーション定義情報136を用いて、当該作業内容が他の開発成果物に影響を及ぼす影響範囲を表示させるソフトウェア、すなわち「ナビゲータ」を実行する処理部である。
図14は、ナビゲーション定義情報136の一例を示す図である。図14に示すように、ナビゲーション定義情報136の一態様としては、作業内容、実施内容および情報源が対応付けられたデータを採用できる。ここで言う「作業内容」とは、開発の作業のカテゴリを指す。また、「実施内容」とは、作業内容が実行された場合に成果として得られる開発成果物のタスクおよび資産種別を指す。また、情報源とは、作業内容が実行される場合に参照される開発成果物のタスクおよび資産種別を指す。
図14に示すように、要件定義書が作成される場合には、作業内容を「要件定義書の作成」として、要件定義書を作成するためには、タスク「document」に分類される資産種別「システム基本仕様」、「業務フロー図」、「データフロー図」、「サブシステム関連図」、「外部インタフェース概要図」、「外部インタフェース一覧」及び「システム機能一覧」などの開発資産を成果物として作成する必要があり、これらの開発資産を作成する際には、タスク「document」に分類される資産種別「組織図」、「業務概要図」、「業務用語一覧」及び「システム要件整理表」などの開発資産が参照される事が定められている。
例えば、クライアント端末30から開発の「作業内容」と、修正対象とする開発成果物の「機能名」または「機能ID」との入力を受け付けた場合を想定する。この場合には、ナビゲータ180は、ナビゲーション定義情報136のうち、当該入力を受け付けた作業内容に定義された開発成果物の一覧を取得する。例えば、作業内容として「要件定義書の作成」が受け付けられていた場合には、「システム基本仕様」、「業務フロー図」、「データフロー図」、「サブシステム関連図」、「外部インタフェース概要図」、「外部インタフェース一覧」及び「システム機能一覧」などの開発成果物が取得される。かかる成果物の一覧を取得後に、ナビゲータ180は、ターゲット資産情報134aのうち、資産種別が先に取得した開発成果物の一覧のいずれかに該当し、かつ先に入力を受けた機能名または機能IDに該当する開発成果物の一覧を取得する。このようにしてターゲット資産情報134aから取得された開発成果物の一覧が修正の必要な開発資産となる。さらに、ナビゲータ180は、ナビゲーション定義情報136に含まれる情報源の参照資産のうち、先に取得された修正の必要な開発資産に対応付けられている開発成果物を抽出する。その上で、ナビゲータ180は、修正の必要な開発資産およびその修正時に参照が定められている参照資産をクライアント端末30に表示させる。
また、クライアント端末30から開発の「作業内容」と、修正対象とする開発成果物の「ファイル名」との入力を受け付けた場合を想定する。この場合には、ナビゲータ180は、ナビゲーション定義情報136のうち、当該入力を受け付けた「作業内容」に定義された開発成果物の一覧を取得する。続いて、ナビゲータ180は、ターゲット資産情報134aのうち、当該入力を受け付けた「ファイル名」に該当するレコードの機能IDを抽出する。その上で、ナビゲータ180は、ターゲット資産情報134aのうち、資産種別が先に取得した開発成果物の一覧のいずれかに該当し、かつ機能IDが先に抽出された機能IDと同一である開発成果物の一覧を取得する。このようにしてターゲット資産情報134aから取得された開発成果物の一覧が修正の必要な開発資産となる。さらに、ナビゲータ180は、ナビゲーション定義情報136に含まれる情報源の参照資産のうち、先に取得された修正の必要な開発資産に対応付けられている開発成果物を抽出する。その上で、ナビゲータ180は、修正の必要な開発資産およびその修正時に参照が定められている参照資産をクライアント端末30に表示させる。
このため、開発関係者は、修正対象の資産種別の表示によって作業内容が他の開発成果物に影響を及ぼす影響範囲を把握できるとともに、情報源となる資産種別の表示によって作業内容を円滑に進めることが可能になる。
[処理の流れ]
続いて、本実施例に係る開発資産管理装置の処理の流れについて説明する。なお、ここでは、開発資産管理装置100によって実行される各種の処理を(1)開発資産収集処理、(2)分類キー情報作成処理、(3)構造ディクショナリ生成処理、(4)開発支援処理の順に説明することとする。
(1)開発資産収集処理
図15は、実施例1に係る開発資産収集処理の手順を示すフローチャートである。この開発資産収集処理は、クライアント端末30によって開発資産情報131に含まれる開発成果物が更新された場合に処理が起動される。
図15に示すように、収集部161は、記憶部130に記憶された収集設定情報132のうち当該更新が実行されたサブシステムに関する開発資産の収集設定を読み出す(ステップS101)。このとき、収集部161は、先に読み出した収集設定のうち「設計ディクショナリ」に関する収集設定に定義された開発資産の配置場所を参照して、「設計ディクショナリ」に関するファイルを優先して収集する。
続いて、分類キー情報作成部162は、「設計ディクショナリ」に関するファイルのうち所定の定義ファイルから、開発成果物を分類するキーとする分類キー情報を作成する「分類キー情報作成処理」を実行する(ステップS102)。
その後、収集部161は、「設計ディクショナリ」以外の収集設定の中から収集設定を1つ選択する(ステップS103)。そして、収集部161は、ステップS103で選択した収集設定に定義された開発資産の配置場所が示すディレクトリを選択する(ステップS104)。その上で、収集部161は、ステップS104で選択したディレクトリ内のファイルを収集する(ステップS105)。
そして、構造ディクショナリ生成部163は、ステップS105で収集されたタスク名「設計ディクショナリ」以外の他のタスク名の収集ファイルが収集設定に定義された管理対象条件を満たすか否かを判定する(ステップS106)。
ここで、収集ファイルが管理対象条件を満たす場合(ステップS106肯定)には、構造ディクショナリ生成部163は、分類キー情報133を用いて、ステップS105で収集されたファイルから、開発成果物を分類可能なインデックスを辞書化した構造ディクショナリを生成する「構造ディクショナリ生成処理」を実行する(ステップS107)。なお、収集ファイルが管理対象条件を満たさない場合(ステップS106否定)には、上記の「構造ディクショナリ生成処理」は実行せずに、ステップS108へ移行する。
そして、ステップS104で選択されたディレクトリ内の全ファイルを収集するまで(ステップS108否定)、上記のステップS105〜ステップS107の処理が繰り返し実行される。その後、ステップS104で選択されたディレクトリ内の全ファイルを収集すると(ステップS108肯定)、収集部161は、当該ディレクトリに配下のディレクトリが存在するか否かを判定する(ステップS109)。
このとき、配下のディレクトリが存在する場合(ステップS109肯定)には、収集部161によって配下のディレクトリが新たに選択され(ステップS104)、上記のステップS104〜ステップS108までの処理が繰り返し実行される。
一方、配下のディレクトリが存在しない場合(ステップS109否定)には、収集部161は、全ての収集設定について処理が終了したか否かを判定する(ステップS110)。
このとき、全ての収集設定について処理が終了していない場合(ステップS110否定)には、新たな収集設定が1つ選択され(ステップS103)、上記のステップS103〜ステップS109までの処理が繰り返し実行される。なお、全ての収集設定について処理が終了した場合(ステップS110肯定)には、処理を終了する。
(2)分類キー情報作成処理
図16は、実施例1に係る分類キー情報作成処理の手順を示すフローチャートである。この分類キー情報作成処理は、図15に示したステップS102に対応する処理であり、「設計ディクショナリ」に関するファイルが収集された場合に処理が起動される。
図16に示すように、分類キー情報作成部162は、タスク名「設計ディクショナリ」の収集ファイルのファイル名と所定の定義ファイルのファイル名、例えば「機能一覧定義」、「ドメイン定義」、「エンティティ定義」や「メッセージ定義」等と比較する(ステップS201)。
このとき、収集ファイルのファイル名が定義ファイルのファイル名と一致する場合(ステップS202肯定)には、分類キー情報作成部162は、定義ファイルの種類に応じて分類キー情報133を作成した上で記憶部130へ登録する(ステップS203及びステップS204)。
一方、収集ファイルのファイル名が定義ファイルのファイル名と一致しない場合(ステップS202否定)には、分類キー情報の作成は実行せずに、ステップS205へ移行する。
そして、タスク名「設計ディクショナリ」に関する全ての収集ファイルについて処理が終了するまで(ステップS205否定)には、上記のステップS201〜ステップS204までの処理が繰り返し実行される。その後、タスク名「設計ディクショナリ」に関する全ての収集ファイルについて処理が終了した場合(ステップS205肯定)には、処理を終了する。
(3)構造ディクショナリ生成処理
図17は、実施例1に係る構造ディクショナリ生成処理の手順を示すフローチャートである。この構造ディクショナリ生成処理は、図15に示したステップS107に対応する処理であり、収集ファイルが管理対象条件を満たす場合(ステップS106肯定)に処理が起動される。
図17に示すように、構造ディクショナリ生成部163は、当該収集ファイルのサブシステム情報を取得する(ステップS301)。続いて、構造ディクショナリ生成部163は、分類キー情報133を用いて、収集ファイルに採番されている各種ID、例えば工程ID、タスクID、機能IDやエンティティIDなどを特定する(ステップS302)。
その後、構造ディクショナリ生成部163は、ステップS302で特定した各種IDをグルーピングした上で収集ファイルに対応付けることによってターゲット資産情報134aを生成する(ステップS303)。その上で、構造ディクショナリ生成部163は、ステップS303で生成されたターゲット資産情報134aを記憶部130へ登録する(ステップS304)。
続いて、構造ディクショナリ生成部163は、当該収集ファイルの内容を解析することによって分析情報を生成する(ステップS305)。その後、構造ディクショナリ生成部163は、タスク別に解析内容が変更して得られる各種の分析情報134bを記憶部130へ登録し(ステップS306)、処理を終了する。
(4)開発支援処理
図18は、実施例1に係る開発支援処理の手順を示すフローチャートである。この開発支援処理は、クライアント端末30から表示ビューの指定を含む開発資産の閲覧要求を受け付けた場合に処理が起動される。
図18に示すように、表示ビューの指定を受け付けると(ステップS401)、エクスプローラ170は、構造ディクショナリ情報134に含まれるターゲット資産情報134aを参照して、ステップS401で受け付けた表示ビューに応じて開発資産情報131に含まれる開発成果物をグルーピングする(ステップS402)。例えば、「工程ビュー」が指定された場合には、工程ID、タスクID、機能IDの順番で開発資産情報131に含まれる開発成果物がグルーピングされる。また、「共通業務ビュー」が指定された場合には、機能ID、工程ID、タスクIDの順番で開発資産情報131に含まれる開発成果物がグルーピングされる。
その後、エクスプローラ170は、ステップS403でグルーピングされることによって階層化された開発資産の一覧画面をクライアント端末30に表示させる(ステップS403)。
そして、クライアント端末30によってファイルが選択された場合(ステップS404)には、エクスプローラ170によって当該ファイルの起動操作の選択肢の他に、当該ファイルの次の工程に割り当てられたファイルの起動操作もしくは当該ファイルの再配置操作が操作の選択肢としてクライアント端末30に表示される。
このとき、ファイルの起動操作が選択された場合(ステップS405肯定)には、エクスプローラ170は、当該ファイルを起動し(ステップS406)、処理を終了する。
また、次の工程に割り当てられたファイルを関連ツールで起動させる操作が選択された場合(ステップS407肯定)には、エクスプローラ170は、次の工程に割り当てられたファイルを関連ツールで起動させ(ステップS408)、処理を終了する。
また、ファイルの再配置操作が選択された場合(ステップS407否定)には、エクスプローラ170は、ファイルの再配置操作を実行し(ステップS409)、処理を終了する。
[実施例1の効果]
上述してきたように、本実施例に係る開発資産管理装置100は、開発成果物の集合である開発資産を収集し、開発資産のうち機能定義ファイルから各開発成果物を分類するキー情報として前記開発資産の機能が辞書化された機能辞書を作成し、開発資産のうち機能定義ファイル以外の開発成果物を対象に、開発成果物の機能を機能辞書を用いて特定するとともに、開発作業の工程が辞書化された工程辞書を用いて開発成果物の工程を特定した上で、特定された開発成果物の機能及び工程が対応付けられた構造辞書を生成し、機能が指定された場合に構造辞書を参照し、各開発成果物を機能でグルーピングした上で同じ機能の開発成果物を工程でグルーピングした開発資産の階層構造を一覧表示させ、工程が指定された場合に構造辞書を参照し、各開発成果物を工程でグルーピングした上で同じ工程の開発成果物を機能でグルーピングした開発資産の階層構造を一覧表示させる。
このため、開発プロジェクトの工程の名称を始め、設計書のドキュメントの命名規約やソースコードのコーディング規約などの開発規約に精通している熟練者は、工程、機能の順にディレクトリを簡単にたどることができる。一方、開発規約に精通していない初心者も、システムの運用や保守で問題や課題が生じた機能から順にディレクトリを簡単にたどることができる。
したがって、本実施例に係る開発資産管理装置100によれば、開発規約に熟練しているか否かを問わず、開発関係者が目的の開発成果物を容易に探索できる。