JP4327686B2

JP4327686B2 - Ｅａに基づく個別システムの構築を支援する方法およびシステム

Info

Publication number: JP4327686B2
Application number: JP2004260416A
Authority: JP
Inventors: 淳岩崎; 雅也勝瑞; 裕二石井; 英二高松; 健松岡
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-09-08
Filing date: 2004-09-08
Publication date: 2009-09-09
Anticipated expiration: 2024-09-08
Also published as: JP2006079224A; US20060053149A1

Description

本発明は、エンタープライズ・アーキテクチャ（ＥＡ）策定後の個別システム開発を支援する方法に関し、特にＥＡの４層の関連に則り、個別システム開発の工数算定、スケジュール作成、及び過去事例の検索を支援する方法に関する。

ＥＡとは、企業や政府機関などの組織の業務手順や情報システムを標準化し、異なる部門間の関連性と情報システムの層の関連性に着目しながら組織全体についての最適化の視点よりシステム開発の設計、構築、運営を行うためのモデルである。企業情報システムの現状(Ａｓ＿Ｉｓ)とあるべき姿(Ｔｏ＿Ｂｅ)の両方について、上位から業務(ＢＡ: Business Architecture)、データ(ＤＡ: Data Architecture)、アプリケーション(ＡＡ: Application Architecture)、インフラ(技術)(ＴＡ: Technology Architecture)のそれぞれ関連性をもった４層のモデルを用いて表現する手法が知られている。

ＥＡをベースにした個別システムの開発では、従来、以下のような作業を人手によって行っていた。
（１）Ａｓ＿ＩｓとＴｏ＿Ｂｅを策定する。
（２）Ａｓ＿ＩｓとＴｏ＿Ｂｅの差分を測る。
（３）アプリケーション層で企業情報システム全体を個別システムという開発単位に分割する。
（４）開発単位ごとの工数を決める。
（５）各開発単位の開発スケジュールを決める。
（６）企業情報システム全体の開発スケジュールを決める。
（７）個別システムの設計文書を作成する。

この種のシステム開発を支援する技術としては、例えば特開２００２−１０９１７３号公報（特許文献１）に記載されているように、工数算出のための式をデータベース中に保持し、ユーザから入力される新規開発か流用設計かなどを示すパラメータによって、製品開発の工数やスケジュール作成を行うものがある。

特開２００２−１０９１７３号公報

従来、単一の情報システムについての開発工数や開発スケジュールを定義する技術は存在した。しかし複数の個別システムについて開発工数を一度に見積もったり開発スケジュールを作成する技術は見当たらない。また従来の技術は、ＥＡで用いられる４層構造を意識していないので、ＥＡの策定結果から企業情報システム全体の開発工数を算定したり、開発スケジュールを作成するには適していない。

ＥＡを策定した後の個別システムの開発は、全体最適のコンセプトを見失うことなく、広い対象範囲を見渡しながら過去の適切な事例を参照しつつ行われねばならないので難しい。

またＥＡをベースにしたシステム構築には、以下のような問題もある。

通常、個別システム開発はアプリケーション単位で行われる。システム開発の過去の事例は、アプリケーション単位で整理され、そのアプリケーションと関連する他の機能やアプリケーション、データについての情報まで整理されていないことが多い。その結果として、システム開発時に過去の事例を参照する場合に、アプリケーションの名前でしか検索できず、過去の大量の事例の中からＥＡで策定した４階層に則った最適な事例を見つけるには工数がかさみ、また時間がかかる。

またＥＡでは粒度の細かい機能を策定しないために、個別システム開発の工数算出は、算出する人の経験に左右され、その品質を一定に保てない。

本発明の目的は、ＥＡを策定した後の個別システムの開発工数見積と過去事例の検索を、ＥＡの４層の関連性を考慮しつつ、担当者の経験に左右されない形式で行う技術を提供することにある。

本発明は、情報処理装置を用いてＥＡに基づく個別システムの構築を支援する技術であって、ＥＡの策定結果を格納するデータベースを基にして個別システムの開発工数を算定し、適切な個別開発事例を取得する技術を特徴とする。開発工数を算定する際には、Ａｓ＿ＩｓとＴｏ＿Ｂｅの機能、データ、インフラの組合せごとに工数を定義する工数定義テーブルについて、この組合せの検索パターンで検索する。また開発事例を検索する際には、機能、データ、連携機能、インフラの組合せごとに過去事例を設定するコンテンツ検索パターンデータベースについて、この組合せの検索パターンで検索する。

本発明によれば、ＥＡ策定後の個別情報システム開発において、あらかじめ定義された工数の算定ロジックによって、設計粒度の細かくないＥＡ策定結果からでもＴｏ＿Ｂｅの開発工数を、ＥＡで定義した４層の関連をたどりながら、担当者の経験に左右されることなく算出することができる。さらに個別開発事例検出ロジックによって、ＥＡの４層の整合性を考慮しつつ、最適な開発事例の提示を行い、過去の事例を参照する手間と時間を大幅に短縮することができる。

ＥＡの４層のうち業務層では企業内の組織とその組織で運営される業務が体系的に定義され、データ層では全ての業務を運営するために必要なデータの内容、またそれらデータの関連性が表される。アプリケーション層では業務に必要なデータを生成する情報処理機能群が定義され、インフラ層では処理の実行に必要なソフトウェア、ハードウェア環境が定義される。

ＥＡを用いたシステム開発では通常システムの現状（Ａｓ＿Ｉｓ）とあるべき姿（Ｔｏ＿Ｂｅ）を描き、そのギャップを埋める形でシステム構築を行う。この際、企業情報システム全体を一度に構築することは大きなリスクを伴うので、通常はシステム全体をある単位で区切って個別システムの開発を行う。このシステムの開発は通常、アプリケーションごとに行われる。これは顧客が要求するシステム機能を実現できるか否か判断でき、またその機能に実際に適応可能な技術を当てはめられるように整理されているのがアプリケーション層だからである。

以下、本発明を実施例について図面に基づいて詳細に説明する。

図１は、本発明の実施例を示すシステム構成図である。本システムは、サーバ101、クライアント103、104、105および両者を接続するネットワーク102から構成される。サーバ101は、データベース群を保持し、データベースに格納されたＥＡの策定結果を用いて将来の個別開発の工数を算出し、開発スケジュールを作成し、過去の開発事例を提示する。クライアント103、104、105は、ネットワーク102を介してサーバ101にデータ入力し、サーバ101から受信したデータを表示する。クライアント103、104、105は、ネットワーク102を介していれば設置距離、設置場所に依存せず、ここでは例として３台が配置されている。

サーバ101の記憶装置は、図示するように工数定義テーブル106、用語マスタデータベース107、ＥＡ策定結果データベース108、コンテンツ検索パターンデータベース109および個別開発事例データベース110を格納する。

サーバ101の主記憶装置111は、ファイル管理部112、ＥＡ成果解析部113、工数算出部114、および事例検索部115の各プログラムを格納するとともに、処理の途中で得られる情報を一時的に格納しておく装置である。ファイル管理部112は、各データベース及び各データベースに格納されているデータへのアクセスを管理する処理部である。ＥＡ成果解析部113は、ＥＡ策定結果データベース108に格納されたＥＡ策定結果を解析して工数定義テーブル106を検索するための検索キーを作成する処理部である。工数算出部114は、ＥＡ成果解析部113が作成した検索キーを元に事例ベースの工数定義テーブル106を検索し、得られた工数を積み上げて個別開発の工数算出を行う処理部である。事例検索部115は、ＥＡ策定結果データベース108に格納されたＥＡ策定結果から事例検索キーを作成し、作成した事例検索キーを元にコンテンツ検索パターンデータベース109を検索し、その結果を元に個別開発事例データベース110を検索して個別開発の事例を引き出す処理部である。サーバ101は、通信制御部116を備える。通信制御部116は、ネットワーク102を介してクライアント103、104、105との間に行われるデータの送受信を制御する制御部である。

クライアント103、104、105の通信制御部117、118、119は、ネットワーク102を介してサーバ101との間に行われるデータの送受信を制御する制御部である。入力装置126、127、128は、ＥＡの策定結果及び個別開発の優先順位を入力する装置である。表示装置123、124、125は、サーバ101での処理結果を表示する装置である。ユーザ入出力部120、121、122は、あらかじめ画面設計された表示画面の様式に従ってサーバ101の工数算出部114の処理結果や、事例検索部115の処理結果を表示装置123、124、125上に表示し、入力装置126、127、128から入力された情報をサーバ101へ送信する。

サーバ101及びクライアント103、104、105は、パーソナルコンピュータ、ワークステーションを含む情報処理装置によって構成され、ファイル管理部112、ＥＡ成果解析部113、工数算出部114、事例検索部115、およびユーザ入出力部120、121、122は、各情報処理装置の主記憶装置に格納されるプログラムを実行することによって実現される。通信制御部116、117、117、119は、ハードウェアおよびソフトウェアによって実現される。なお事例ベースの工数定義テーブル106を初めとするデータベース群やサーバ101のファイル管理部112をネットワークを介してサーバ101と接続される別のサーバによって実現しても良い。

事例ベースの工数定義テーブル106には図２及び図３で示すような工数算出に必要な情報が格納されており、サーバ101は工数算出時に事例ベースの工数定義テーブル106より必要な情報を読み出す。

図２は、「機能別工数定義表」の例を示す図である。この表は、「機能」、「データ」、「インフラ」に着目し、Ａｓ＿ＩｓからＴｏ＿Ｂｅに移行するときのアプリケーションの開発工数を過去事例を元に定義するものである。ここでは、あるアプリケーションについて、Ａｓ＿Ｉｓの「機能」(201)、「データ」(202)、「インフラ」(203)からＴｏ＿Ｂｅの「機能」(204)、「データ」(205)、「インフラ」(206)にシステムを再構築した場合にかかる工数(人月)(207)を「機能」、「データ」、「インフラ」のすべての組み合わせごとに定義している。図２の例では、業務「受注」が「受注受付」「受注登録」などいくつかの機能に分かれていることを示している。また１つの機能又は関連するいくつかの機能が１つのアプリケーションに対応する。またＡｓ＿Ｉｓ機能「受注受付」、Ａｓ＿Ｉｓデータ「引合情報、顧客情報、商品情報、受注情報」、Ａｓ＿Ｉｓインフラ「開発言語１、データベースソフトウェアＡ」のシステムから、Ｔｏ＿Ｂｅ機能「受注受付」、Ｔｏ＿Ｂｅデータ「受付情報、顧客情報、商品情報、受注情報」、Ｔｏ＿Ｂｅインフラ「開発言語１、データベースソフトウェアＡ」のシステムを構築する場合に、プログラム変更やデータ変更のために０．５人月かかるということを示している(208)。機能「受注登録」については、「データ」および「インフラ」それ自体の変更はないが、他の機能との関連でテストなどの必要があり、ここでは０．５人月の工数を設定している。

図３は、「データベースソフトウェア別工数定義表」の例である。ここでエンティティとは、データベース上で情報を管理する単位を意味する。この表はひとつのエンティティを作成するのに必要な標準の工数(301)を、エンティティを管理することとなるインフラ(データベースソフトウェア)(302)ごとに定義している。ここでは、インフラがデータベースソフトウェアＡの場合には、１エンティティ作成するのに、０．３人月かかることを示している(303)。

図４は、用語マスタデータベース107の例を示す図である。用語マスタデータベース107は、業務401、データ402およびインフラ403に分けて各々使用される用語を格納する。業務401は、業務中の機能名を登録する。この表は、ＥＡの策定結果があらかじめ定義された業務名、データ名、インフラ名に準拠しているか否かチェックするために使用される。なおここで業務名とは、図５に示す「機能体系表」の「業務レベル２」(502)で使用される機能名を指し、「業務レベル０」および「業務レベル１」で使用される業務名を含まない。

ＥＡ策定結果データベース108は、ユーザが策定した図５〜１１で示すようなＥＡの策定結果を格納する。

図５の「機能体系表」はＥＡのＢＡ層(第１層)で使われている業務について業務区分ごとに「業務レベル０」から「業務レベル２」まで３段階に亘って細分化している(501)。ＥＡでは業務機能構成図と呼ばれる図を用いて、業務機能を３段階に細分化する手法が一般的であるため、本実施例においても図５のような業務体系を定義する図もしくは表を作成するために、レベル２までの業務機能を設定することとする。前述した図４「用語マスタ」を利用する用語チェックでは、「業務機能体系表」の「業務レベル２」(502)についてチェックすることとする。

図６の「機能＿データ対応表」は、ＢＡ層とＤＡ層(第２層)を結びつけるために図５「機能体系表」の「業務レベル２」(502)で定義された機能がそれぞれどんなデータを必要とするのかを定義している。ここでは、「受注受付」という機能が必要するデータは、「受注情報、顧客情報、商品情報、引合情報」であることを示している(601)。

図７の「データ＿エンティティ対応表」は、図６に設定したデータとＤＡ層で定義するエンティティとの対応を定義している。

図８の「アプリケーション機能構成表」は、ＡＡ層(第３層)とＢＡ層を結びつけるためにＥＡ策定の対象となった拠点ごとに使用するアプリケーションとそのアプリケーションが対象とする機能を定義している。ここでは、現在東京には「販売アプリケーション」があり、「受注受付」(801)と「受注登録」(802)の機能を持っており、これとは別のアプリケーションである「生産管理アプリケーション」には「工程展開」(803)という機能がある。大阪の拠点にある「販売アプリケーション」にも東京と同様の「受注受付」(804)と「受注登録」(805)の機能が記載されている。この場合、「販売アプリケーション」が東京と大阪で存在するが、それぞれ別のアプリケーションとして定義することとする。

図９の「アプリケーション関連表」は、ＥＡで策定したＡＡ層のアーキテクチャに関連する二つのアプリケーション(「連携元アプリケーション」と「連携先アプリケーション」)、およびアプリケーション間の連携をつかさどる機能とアプリケーション間でやり取りされるデータを定義している。ここでは、「販売アプリケーション」という連携元に対して、「生産アプリケーション」が「納期確認」機能を利用して、「納期情報」というデータをやり取りすることを示している(901)。

図１０の「Ａｓ＿Ｉｓ＿Ｔｏ＿Ｂｅアプリケーション対応表」は、Ａｓ＿ＩｓのアプリケーションとＴｏ＿Ｂｅのアプリケーションの対応が、「機能」、「データ」、「連携機能」という区分ごとに定義されている。図１０で定義しているＡｓ＿ＩｓもしくはＴｏ＿Ｂｅの「要素名」とは、「機能」、「データ」、「連携機能」という区分における具体的な機能名、データ名、連携機能名を示している(1001)。例えば、１行目は「Ａｓ＿Ｉｓの販売アプリケーション」の「機能」区分である「受注受付」はＴｏ＿Ｂｅでは「販売アプリケーション」の「受注受付」機能になることを表している(1002)。３行目ではＡｓ＿Ｉｓの「販売アプリケーション」の「データ」区分である「受注情報」はＴｏ＿Ｂｅでは「販売アプリケーション」の「受注情報」として用いられることを表している(1003)。またＡｓ＿Ｉｓのアプリケーション名、要素名に−(ハイフン)が記入されているものは新規に開発されるアプリケーションに対応する要素であるため、現行要素が存在しないことを示す(1004)。

図１１の「アプリケーション＿インフラ対応表」には、ＴＡ層(第４層)と他の３層を結びつけるために各アプリケーションの「機能」、「データ」、「連携機能」を実現するインフラ(言語やソフト)を定義している。例えば表の１行目は、「販売アプリケーション」の機能である「受注受付」は「開発言語１」で実現されていることを示している(1101)。ここで言語(1104)はアプリケーションの開発に用いる言語を示し、ソフト(1105)は、データの管理のために導入するデータベース管理システムを示す。

コンテンツ検索パターンデータベース109には、図１２で例を示すようなコンテンツ検索パターン定義表が格納されている。この表は「機能」(1201)、「データ」(1202)、「連携機能」(1203)、「インフラ」(1204)の組み合わせごとに個別開発事例で蓄積したドキュメント名を定義している(1205)。この定義表の「機能」「データ」「連携機能」「インフラ」で用いられる用語の組合せがコンテンツ検索パターンとなる。この表は２つのコンテンツ検索パターンの例を示しており、上段が「連携機能」のある場合の検索パターン、下段が「連携機能」のない場合の検索パターンを示している。

個別開発事例データベース110には、コンテンツ検索パターンデータベースで定義した全ての個別開発事例の設計書そのものが格納されている。

サーバ101の主記憶装置111には処理の過程で図１３、図１４、図１５で例を示すような情報が格納される。以下に、それぞれの情報の内容を説明する。

図１３の「機能別工数検索キー」は、工数定義テーブル106を検索するためにキーとして作成される情報であり、「Ａｓ＿Ｉｓ機能」(1301)、「Ａｓ＿Ｉｓデータ」(1302)、「Ａｓ＿Ｉｓインフラ」(1303)、「Ｔｏ＿Ｂｅ機能」(1304)、「Ｔｏ＿Ｂｅデータ」(1305)、「Ｔｏ＿Ｂｅインフラ」(1306)の６列で構成されている。１つの機能についてこの６列に出現するすべての用語の組合せが検索キーとなる。

図１４の「データベースソフトウェア別工数検索キー」は、事例ベースの工数定義テーブル106中の情報を元に工数を算出するための検索キーとして作成される情報であり、「エンティティ数」(1401)、「インフラ」(1402)の２列で構成されている。ここでインフラ名が検索キーとなる。

図１５の「事例検索キー」は、過去の事例をコンテンツ検索パターンデータベース109を検索するためにキーとして作成される情報であり、「機能」(1501)、「データ」(1502)、「連携機能」(1503)、「インフラ」(1504)の４列から構成される。この４列の用語の組合せがコンテンツ検索パターンとして検索のために使用される。

以下に本システムの具体的な処理の流れを図１６のフローチャートを用いて説明する。まずユーザはＥＡの成果物として、図５〜図１１の表で示される情報の全てを入力装置126、127、128を通してサーバ101に入力し、ＥＡ成果解析部113がこれらの情報を受領する(1601)。

ＥＡ成果解析部113は、入力されたＥＡの策定結果を一旦ＥＡ策定結果データベース108に格納し、その策定結果が用語マスタデータベース107で定義された用語を使用しているか否かチェックする（ステップ1602）。用語マスタデータベース107の業務401で定義される用語については、図５の「機能体系表」の「業務レベル２」列(502)、図６の「機能＿データ対応表」の「機能」列(602)、図８の「アプリケーション機能構成表」の「機能」列(806)、図９の「アプリケーション関連表」の「連携機能」列(902)、図１０の「Ａｓ＿Ｉｓ＿Ｔｏ＿Ｂｅアプリケーション対応表」の「区分」列(1005)に「機能」及び「連携機能」と書かれている行の「Ａｓ＿Ｉｓ要素名」列と「Ｔｏ＿Ｂｅ要素名」列(1001)、図１１の「アプリケーション＿インフラ対応表」の「区分」列(1102)に「機能」及び「連携機能」と書かれている行の「要素名」列(1103)がチェックの対象となる。データ４０２で定義される用語については、図６の「機能＿データ対応表」の「データ」列(603)、図７の「データ＿エンティティ対応表」の「データ」列(701)、図９の「アプリケーション関連表」の「データ」列(903)、図１０の「Ａｓ＿Ｉｓ＿Ｔｏ＿Ｂｅアプリケーション対応表」の「区分」列(1005)に「データ」と書かれている行の「Ａｓ＿Ｉｓ要素名」列と「Ｔｏ＿Ｂｅ要素名」列(1001)、図１１の「アプリケーション＿インフラ対応表」の「区分」列(1102)に「データ」と書かれている行の「要素名」列(1103)がチェックの対象となる。インフラ403で定義される用語については、図１１のアプリケーション＿インフラ対応表の言語列(1104)、ソフト列(1105)がチェックの対象となる。ＥＡの策定結果が定義された用語に準拠していない場合は、ＥＡ成果解析部113は、ユーザにメッセージを表示してその旨を知らせ、予め定義された用語を使用するようＥＡ策定結果を修正入力させる。

ＥＡの策定結果が定義された用語に準拠している場合は、ＥＡ成果解析部113がＥＡの策定結果を解析する（ステップ1603）。その処理手順は以下のとおりである。

まずＥＡ成果解析部113は、図８の「アプリケーション機能構成表」を参照し、拠点とＴｏ＿Ｂｅのアプリケーションとの組合せを取得する。次にＥＡ成果解析部113は、取得した拠点のアプリケーションについて図１０の「Ａｓ＿Ｉｓ＿Ｔｏ＿Ｂｅアプリケーション対応表」を参照し、現在の(Ａｓ＿Ｉｓの)アプリケーションに含まれる機能、データ、および連携機能が将来の(Ｔｏ＿Ｂｅの)どのアプリケーションのどの「機能」、「データ」、および「連携機能」で実現されるのかについての情報を取得する。図１０の例で述べると、図８の表の一行目にある「販売アプリケーション」の「受注受付」という機能は、「販売アプリケーション」の「受注受付」という機能となると判断される。

次にＥＡ成果解析部113は、図１０の「Ａｓ＿Ｉｓ＿Ｔｏ＿Ｂｅアプリケーション対応表」にある機能名について図６の「機能_データ対応表」を参照し、対応するデータを取得する。「機能_データ対応表」は、各機能がどのようなデータを使用するのかを定義しており、ＥＡ成果解析部113は、機能ごとのデータの対応をチェックする。機能ごとに対応するデータが一致していれば、以下の処理対象のデータとして確保する。図１０の「販売アプリケーション」の「受注受付」機能を例にとると、「機能_データ定義表」において「受注受付」機能に対応する「受注情報」、「顧客情報」、「商品情報」、「引合情報」というデータが取得される。

ＥＡ成果解析部113は、更に図１１の「アプリケーション＿インフラ対応表」を参照し、図１０の「Ａｓ＿Ｉｓ＿Ｔｏ＿Ｂｅアプリケーション対応表」と図６の「機能＿データ対応表」から求められた機能とデータがそれぞれどんな言語とデータベースソフトウェアで実現されているのかを図１１の「アプリケーション＿インフラ対応表」から求める。図１１の例では「販売アプリケーション」に使われる「受注受付」機能は、「開発言語１」によって構築され、「受注情報」、「顧客情報」、「商品情報」、「引合情報」は、それぞれ「開発言語１」と「データベースソフトウェアＡ」を利用して実装されている。

ＥＡ成果解析部113は、求めた情報から図１３に示す「機能別工数検索キー」を作成し、主記憶装置111内に保持する(ステップ1604)。

次にＥＡ成果解析部113は、データをエンティティに集約する（ステップ1605）。その処理手順は以下のとおりである。ＥＡ成果解析部113は、図６に示す「機能＿データ対応表」についてチェック済の処理対象のＴｏ＿Ｂｅの「データ」名をキーにして図７の「データ＿エンティティ対応表」を参照し、対応するエンティティを取得する（ステップ1605）。図７の例では図６の「受注情報」、「顧客情報」、「商品情報」、「引合情報」の４つのデータについて、「受注」、「顧客」、「商品」の３つのエンティティを取得する。さらにＥＡ成果解析部113は、処理対象の「データ」をキーにして図１１の「アプリケーション＿インフラ対応表」を参照し、対応するソフト1105を取得する。図７の例では「受注情報」、「顧客情報」、「商品情報」、「引合情報」に対応するインフラとして「データベースソフトウェアＡ」が取得される。

ＥＡ成果解析部113は、取得したインフラのエンティティ数を計数し、図１４に示す「データベースソフトウェア別工数検索キー」を作成して主記憶装置111内に保持する(ステップ1606)。

ＥＡ成果解析部113は、「機能別工数検索キー」および「データベースソフトウェア別工数検索キー」を工数算出部114へ引き渡す。

サーバ101の工数算出部114は、受け取った「機能別工数検索キー」および「データベースソフトウェア別工数検索キー」を元に事例ベースの工数定義テーブル106を検索する(ステップ1607)。工数算出部114は、「機能別工数検索キー」を用いて工数定義テーブル106の「機能別工数定義表」を検索し、検索キーに対応する工数207を取得し、機能ごとの工数を算定する（ステップ1608）。たとえば図１３に示す「機能別工数検索キー」の例で、「機能別工数定義表」を検索すると、Ａｓ＿Ｉｓ「受注受付」、Ｔｏ＿Ｂｅ「受注受付」の対応では「０．５人月」の工数がかかることとなる。

次に工数算出部114は、「データベースソフトウェア別工数検索キー」のインフラ名を用いてデータベースソフトウェア別工数定義表を検索し、検索キーに対応する工数／エンティティ301を取得し、エンティティについての工数を算定する（ステップ1609）。「データベースソフトウェア別工数検索キー」のインフラ名をキーに「データベースソフトウェア別工数定義表」を参照すると、エンティティごとの工数が示されているので、「データベースソフトウェア別工数検索キー」のエンティティ数とエンティティごとの工数を掛け合わせて各インフラごとの工数を算出する。図１４と図３の例では「データベースソフトウェアＡ」で実現されているエンティティが３つであるので、図３の「データベースソフトウェアＡ」の持つ「０．３人月」に３を掛け合わせて「０．９人月」がここから導き出される工数となる。工数算出部114は、これら二通りの方法で求められた工数を足すことによってひとつの機能を実現するのにどれくらいの工数がかかるのかを求める（ステップ1610）。既出の例では「機能別工数定義表」より求められた「０．５人月」と、「データベースソフトウェア別工数定義表」より求められた「０．９人月」を加えて、「１．４人月」が受注受付機能を実現するのに必要な工数になる。

ＥＡ成果解析部113と工数算出部114は、以上の工数算出をアプリケーションにある機能ごとに行い、ひとつのアプリケーションの実現にどれだけの工数が必要なのかを算出する。さらにＥＡ成果解析部113と工数算出部114は、ＥＡ策定結果データベース108にある全てのアプリケーションについて同様の計算を行い、各アプリケーション実現にかかる工数をクライアントの表示装置123,124,125に出力する(ステップ1611)。

次に工数算出部114は、ユーザに上で算出したいくつかのアプリケーションの個別開発の優先順位と開発人員を入力させる(ステップ1612)。工数算出部114は、以上の処理結果の情報を元に開発スケジュールを作成し(ステップ1613)、クライアントの表示装置123,124,125に出力する(ステップ1614)。

次にＥＡを用いた個別開発の過去の事例を検索する例を図１７のフローチャートを用いて説明する。まずユーザはＥＡの成果物として図５〜図１１の表で示される情報の全てを入力装置126、127、128のいずれかからサーバ101に入力し、事例検索部115がこれらの情報を受領する(ステップ1701)。次にサーバ101の事例検索部115は、「Ａｓ＿Ｉｓ_Ｔｏ＿Ｂｅアプリケーション対応表」を参照し、「Ｔｏ＿Ｂｅアプリケーション名」ごとに「機能」、「データ」、「連携機能」を抽出する（ステップ1702）。例えば、図１０のような表の場合、「販売アプリケーション」の機能は「受注受付」と「受注売上管理」、データは「受注情報」と「顧客情報」、連携機能は「納期確認」、ということになる。次に事例検索部115は、図１１の「アプリケーション＿インフラ対応表」から抽出された「機能」、「データ」、「連携機能」に対応する「開発言語」、「ソフトウェア」を取得する。図１１に示された例に当てはめると、「受注受付」機能は「開発言語１」で実現され、「受注情報」は「開発言語１」と「データベースソフトウェアＡ」を用い、「納期確認」連携機能は「開発言語１」を用いる。事例検索部115は、これらの情報から図１５に示す「事例検索キー」を作成して主記憶装置上に保持する。

次に事例検索部115は、図１５に示された４列の用語をキーにしてコンテンツ検索パターンデータベース109を検索する(ステップ1703)。過去の事例が存在する場合は（ステップ1704YES）、事例検索キーにマッチするコンテンツドキュメント1205が取得される。図１２の例では上段の用語群が、「機能」、「データ」、「連携機能」、「インフラ」の全ての組み合わせでマッチしており、過去の事例として「基本設計書No.552」、「詳細設計書No.552」を取得する。

事例検索部115は、ファイル管理部112に「基本設計書No.552」と「詳細設計書No.552」を検索するよう指示する。ファイル管理部112は、個別開発事例データベース110を検索する(ステップ1705)。事例検索部115は、得られた設計ドキュメントを個別開発事例としてクライアントの表示装置123,124,125のいずれかに表示する(ステップ1706)。

なお事例検索部115が主記憶装置111上に保持した事例検索キーが、コンテンツ検索パターンデータベース109内に存在しなかった場合、事例検索部115は、該当する過去の個別開発事例が存在しないとする内容のメッセージを表示装置に出力する(ステップ1707)。

実施形態のシステムの構成図である。実施形態の機能別工数定義表の例である。実施形態のデータベースソフトウェア別工数定義表の例である。実施形態の用語マスタ表の例である。実施形態の機能体系表の例である。実施形態の機能＿データ対応表の例である。実施形態のデータ＿エンティティ対応表の例である。実施形態のアプリケーション機能構成表の例である。実施形態のアプリケーション関連表の例である。実施形態のＡｓ＿Ｉｓ＿Ｔｏ＿Ｂｅアプリケーション対応表の例である。実施形態のアプリケーション＿インフラ対応表の例である。実施形態のコンテンツ検索パターン定義表の例である。実施形態の機能別工数検索キーの例である。実施形態のデータベースソフトウェア別工数検索キーの例である。実施形態の事例検索キーの例である。実施形態の個別システム開発工数算定の処理フローである。実施形態の個別システム開発事例検索の処理フローである。

符号の説明

101：サーバ、103、104、105：クライアント、106：工数定義テーブル、107：用語マスタデータベース、108：ＥＡ策定結果データベース、109：コンテンツ検索パターンデータベース、110：個別開発事例データベース、113：ＥＡ成果解析部、114：工数算出部、115：事例検索部。

Claims

クライアントとネットワークを介して接続するサーバによって、エンタープライズ・アーキテクチャ（ＥＡ）に基づく個別システムの構築を支援する方法であって、
前記サーバの記憶装置は、前記ＥＡの策定後の現状（As‐Is）からあるべき姿（To‐Be）へ移行するときのアプリケーション開発工数を過去の事例を元に定義した機能別工数定義表と、前記ＥＡのインフラ層を実現するインフラとしてのデータベース上でデータを管理する単位であるエンティティを作成するために必要な工数を、前記インフラとしてのデータベースと対応付けて定義したデータベースソフトウェア別工数定義表とを含む工数定義テーブル、および、前記ＥＡの業務層とデータ層とを対応付ける、前記業務層で定義された機能と該機能が用いるデータとを定義した機能‐データ対応表と、前記機能‐データ対応表で定義された前記データと前記エンティティとの対応を定義するデータ‐エンティティ対応表と、前記ＥＡのアプリケーション層と前記業務層とを対応付けるアプリケーションと該アプリケーションの対象の機能とを定義したアプリケーション‐機能構成表と、機能及びデータのいずれかの区分に応じて、As‐Isのアプリケーション及び該アプリケーションの対象の前記区分における要素とTo‐Beのアプリケーション及び該アプリケーションの対象の前記区分における要素とを対応付けるAs‐Is‐To‐Beアプリケーション対応表と、前記区分に応じて、アプリケーションと該アプリケーションの要素を実現する前記ＥＡの前記インフラ層との対応付けを定義するアプリケーション‐インフラ対応表とを含むＥＡ策定結果を格納し、
前記サーバは、前記アプリケーション‐機能構成表に定義される前記アプリケーションと該アプリケーションの対象の前記区分における要素とを、As‐IsとTo‐Beとに関して、前記As‐Is‐To‐Beアプリケーション対応表から取得し、
前記As‐IsとTo‐Beとに関して取得した前記アプリケーションの対象の前記区分における要素を実現する前記インフラとしてのデータベースを前記アプリケーション‐インフラ対応表から取得し、
前記As‐IsとTo‐Beとに関して取得した、前記アプリケーションの対象の前記区分における要素である機能、前記区分における要素であるデータ、及び前記区分における要素を実現するインフラとを対応付けた機能別工数検索キーを用いて前記機能別工数定義表を検索して、前記アプリケーション開発工数を取得し、
取得した前記インフラとしてのデータベースに対応するエンティティ当たりの工数を前記データベースソフトウェア別工数定義表から取得し、前記アプリケーションの対象の前記区分における要素である機能に対応するデータを前記機能‐データ対応表から取得し、取得した前記データに対応するエンティティの数を前記データ‐エンティティ対応表から取得し、
取得した前記インフラとしてのデータベースに対応するエンティティ当たりの工数と取得した前記エンティティの数を掛け、さらに取得した前記アプリケーション開発工数を加え、
前記加えた開発工数を前記アプリケーションが実現する個別システムの開発工数として前記クライアントに前記ネットワークを介して出力することを特徴とする個別システムの構築を支援する方法。
前記記憶装置が格納する前記As‐Is‐To‐Beアプリケーション対応表は、前記ＥＡで策定した２つのアプリケーションの関連を示す連携機能を前記区分に含み、
前記記憶装置は、さらに個別開発事例の設計書を格納する個別開発事例データベースと、
前記業務層で定義された機能、該機能が用いるデータ、該機能を実現するインフラ、および前記個別開発事例データベースに格納される前記設計書を示すコンテンツドキュメントとを対応付けて格納するコンテンツ検索パターンデータベースとを格納し、
前記サーバは、前記As‐Is‐To‐Beアプリケーション対応表から、前記To‐Beのアプリケーション及び該アプリケーションの対象の前記区分における要素としての機能、データ及び連携機能とを取得し、
前記アプリケーション‐インフラ対応表から、前記To‐Beのアプリケーションの対象の前記区分における要素を実現する前記インフラとしてのデータベースを取得し、
取得した前記機能、前記データ及び前記連携機能と前記インフラとしてのデータベースとを対応付けた事例検索キーを用いて前記コンテンツ検索パターンデータベースを検索して、前記コンテンツドキュメントを取得し、
取得した前記コンテンツドキュメントを基に、前記個別開発事例データベースに格納される前記設計書を取得し、
取得した前記設計書を前記クライアントに前記ネットワークを介して出力することを特徴とする請求項１記載の個別システムの構築を支援する方法。
エンタープライズ・アーキテクチャ（ＥＡ）の策定後の現状（As‐Is）からあるべき姿（To‐Be）へ移行するときのアプリケーション開発工数を過去の事例を元に定義した機能別工数定義表と、前記ＥＡのインフラ層を実現するインフラとしてのデータベース上でデータを管理する単位であるエンティティを作成するために必要な工数を、前記インフラとしてのデータベースと対応付けて定義したデータベースソフトウェア別工数定義表とを含む工数定義テーブル、および、前記ＥＡの業務層とデータ層とを対応付ける、前記業務層で定義された機能と該機能が用いるデータとを定義した機能‐データ対応表と、前記機能‐データ対応表で定義された前記データと前記エンティティとの対応を定義するデータ‐エンティティ対応表と、前記ＥＡのアプリケーション層と前記業務層とを対応付けるアプリケーションと該アプリケーションの対象の機能とを定義したアプリケーション‐機能構成表と、機能及びデータのいずれかの区分に応じて、As‐Isのアプリケーション及び該アプリケーションの対象の前記区分における要素とTo‐Beのアプリケーション及び該アプリケーションの対象の前記区分における要素とを対応付けるAs‐Is‐To‐Beアプリケーション対応表と、前記区分に応じて、アプリケーションと該アプリケーションの要素を実現する前記ＥＡの前記インフラ層との対応付けを定義するアプリケーション‐インフラ対応表とを含むＥＡ策定結果を格納する記憶装置、
前記記憶装置を含み、前記アプリケーション‐機能構成表に定義される前記アプリケーションと該アプリケーションの対象の前記区分における要素とを、As‐IsとTo‐Beとに関して、前記As‐Is‐To‐Beアプリケーション対応表から取得し、前記As‐IsとTo‐Beとに関して取得した前記アプリケーションの対象の前記区分における要素を実現する前記インフラとしてのデータベースを前記アプリケーション‐インフラ対応表から取得し、前記As‐IsとTo‐Beとに関して取得した、前記アプリケーションの対象の前記区分における要素である機能、前記区分における要素であるデータ、及び前記区分における要素を実現するインフラとを対応付けた機能別工数検索キーを用いて前記機能別工数定義表を検索して、前記アプリケーション開発工数を取得し、取得した前記インフラとしてのデータベースに対応するエンティティ当たりの工数を前記データベースソフトウェア別工数定義表から取得し、前記アプリケーションの対象の前記区分における要素である機能に対応するデータを前記機能‐データ対応表から取得し、取得した前記データに対応するエンティティの数を前記データ‐エンティティ対応表から取得し、取得した前記インフラとしてのデータベースに対応するエンティティ当たりの工数と取得した前記エンティティの数を掛け、さらに取得した前記アプリケーション開発工数を加え、前記加えた開発工数を前記アプリケーションが実現する個別システムの開発工数として出力するサーバ、および、
前記サーバとネットワークを介して接続し、前記サーバから出力された前記個別システムの開発工数を表示するクライアント
を有することを特徴とする個別システムの構築を支援するシステム。
前記記憶装置が格納する前記As‐Is‐To‐Beアプリケーション対応表は、前記ＥＡで策定した２つのアプリケーションの関連を示す連携機能を前記区分に含み、
前記記憶装置は、さらに個別開発事例の設計書を格納する個別開発事例データベースと、前記業務層で定義された機能、該機能が用いるデータ、該機能を実現するインフラ、および前記個別開発事例データベースに格納される前記設計書を示すコンテンツドキュメントとを対応付けて格納するコンテンツ検索パターンデータベースとを格納し、
前記サーバは、前記As‐Is‐To‐Beアプリケーション対応表から、前記To‐Beのアプリケーション及び該アプリケーションの対象の前記区分における要素としての機能、データ及び連携機能とを取得し、前記アプリケーション‐インフラ対応表から、前記To‐Beのアプリケーションの対象の前記区分における要素を実現する前記インフラとしてのデータベースを取得し、取得した前記機能、前記データ及び前記連携機能と前記インフラとしてのデータベースとを対応付けた事例検索キーを用いて前記コンテンツ検索パターンデータベースを検索して、前記コンテンツドキュメントを取得し、取得した前記コンテンツドキュメントを基に、前記個別開発事例データベースに格納される前記設計書を取得し、取得した前記設計書を前記クライアントに前記ネットワークを介して出力し、
前記クライアントは前記サーバが出力した前記設計書を表示することを特徴とする請求項３記載の個別システムの構築を支援するシステム。