(57)【要約】【課題】クラスの親子関係を考慮して、削減したいコストに合った修正すべきクラスの組み合わせを的確に把握する。【解決手段】ソフトウェア設計のためのデータ構造を抽象化して表現した複数のクラス図によって構成される概念モデルを用いたシステム開発において、システム移行後の評価対象の概念モデルの修正を支援する概念モデル修正支援プログラムは、コンピュータに、前記評価対象の概念モデルと、前記評価対象の概念モデルに対して算出されたコストから削減したいコストを入力する入力機能と、前記評価対象の概念モデルを構成する各クラスに対して、前記入力されたコストに相当する削減対象のクラスの組み合わせを、クラスの親子関係を考慮して選定する削減対象クラス選定機能と、前記削減対象のクラスの組み合わせを出力する出力機能とを実現させる。【選択図】図１
2018085067.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェア設計のためのデータ構造を抽象化して表現した複数のクラス図によって構成される概念モデルを用いたシステム開発において、システム移行後の評価対象の概念モデルの修正を支援する概念モデル修正支援プログラムであって、コンピュータに、
前記評価対象の概念モデルと、前記評価対象の概念モデルに対して算出されたコストから削減したいコストを入力する入力機能と、
前記評価対象の概念モデルを構成する各クラスに対して、前記入力されたコストに相当する削減対象のクラスの組み合わせを、クラスの親子関係を考慮して選定する削減対象クラス選定機能と、
前記削減対象のクラスの組み合わせを出力する出力機能と、
を実現させる概念モデル修正支援プログラム。
【請求項２】
当該概念モデル修正支援プログラムは、前記コンピュータに、
前記削減対象のクラス毎に、前記削減対象のクラスが削除されたときのコスト削減量を、前記削減対象のクラスの親子関係に基づいて算出する削減コスト算出機能
を更に実現させる、請求項１に記載の概念モデル修正支援プログラム。
【請求項３】
前記削減コスト算出機能は、前記削減対象のクラスが親クラスであるか子クラスであるかに応じて設定されたコスト換算係数を用いて、コスト削減量を算出する、請求項２に記載の概念モデル修正支援プログラム。
【請求項４】
前記削減コスト算出機能は、前記削減対象のクラスが親クラスである場合、依存関係のある子クラスのコスト換算係数を高くして、コスト削減量を算出する、請求項２に記載の概念モデル修正支援プログラム。
【請求項５】
前記入力機能は、システム移行前の起点となる概念モデルを更に入力し、
当該概念モデル修正支援プログラムは、前記コンピュータに、
クラスの親子関係を考慮して、前記起点となる概念モデルから前記評価対象の概念モデルへの移行に伴うコストを算出する初期コスト算出機能
を更に実現させる、請求項１乃至４のうちいずれか１項に記載の概念モデル修正支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概念モデルを用いたシステム開発において、概念モデルの修正を支援する概念モデル修正支援プログラムに関する。
【背景技術】
【０００２】
オブジェクト指向プログラミングにおけるソースコードは、設計段階で作成された各クラス図に基づいてコーディングされる。そのため、現行システムから次期システムへの移行に伴い、クラスに変更があった場合には、プログラム各部への影響が生じることなり、特にソフトウェアが大規模化するにしたがって、プログラム各部への影響が大きくなる。
【０００３】
ソフトウェアの開発規模を算出する１つの手法として、ファンクションポイント法がある（非特許文献１参照）。ファンクションポイント法は、ソフトウェアの機能に着目し、その処理内容に応じてポイント（点数）を付けてソフトウェア全体に対する開発規模や工数を算出する手法である。ファンクションポイント法は、プログラミング前に必要な機能が抽出できた段階で開発規模を概算し、システム開発コストを算出することができる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】"情報マネジメント用語辞典：ファンクションポイント法"，インターネット，<http://www.itmedia.co.jp/im/articles/0504/27/news126.html>，２０１６年１１月１日検索
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のファンクションポイント法は、ソフトウェアの機能に着目して開発規模や工数を算出するため、ある程度実装する機能等が明確にならなければシステム開発コストを算出することができない。すなわち、ファンクションポイント法では、設計段階の中でもある程度設計が作り込まれた段階でのコスト算出となるため、ソフトウェアの開発に要するコストがわからない段階で設計をある程度進めることとなり、開発要否等の判断によっては、手戻りが大きいという課題がある。
【０００６】
手戻りを少なくするためには、クラス図が作成された時点のような設計の早い段階でコストを算出することが重要である。設計の早い段階でのコスト算出は、関係者が意識を共有して作業を進めることができ、コスト算出自体に要する時間も短くなると考えられる。
【０００７】
一方、クラス図からコストが算出できたとしても、算出したコストが想定コストより大きくなることがしばしば存在する。想定コストの範囲内にコストを抑えるために所定の額のコスト削減が必要となる場合に、単純にクラスごとのコストを比較してクラス図を修正したとしても、設計段階のクラスには親子関係があるため、親子関係に引きずられて大幅にコストが下がったり、想定したほどコストが下がらなかったりする課題がある。
【０００８】
このように、算出されたコストが想定とずれていた場合に、許容されるコストとの差分を考慮して、クラス図のどの部分を修正すれば許容されるコストに合ったものとするか修正部分を明確にすることができなかった。
【０００９】
本発明は、クラスの親子関係を考慮して、削減したいコストに合った修正すべきクラスの組み合わせを的確に把握することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一形態に係る概念モデル修正支援プログラムは、
ソフトウェア設計のためのデータ構造を抽象化して表現した複数のクラス図によって構成される概念モデルを用いたシステム開発において、システム移行後の評価対象の概念モデルの修正を支援する概念モデル修正支援プログラムであって、コンピュータに、
前記評価対象の概念モデルと、前記評価対象の概念モデルに対して算出されたコストから削減したいコストを入力する入力機能と、
前記評価対象の概念モデルを構成する各クラスに対して、前記入力されたコストに相当する削減対象のクラスの組み合わせを、クラスの親子関係を考慮して選定する削減対象クラス選定機能と、
前記削減対象のクラスの組み合わせを出力する出力機能と、
を実現させることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、削減したいコストに合った修正すべきクラスの組み合わせを的確に把握することが可能になる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施例に係る概念モデル修正支援装置の機能ブロック図
【図２】本発明の実施例に係る概念モデル修正支援装置における処理を示すフローチャート
【図３】概念モデルの定義を示す図
【図４】概念モデルの変更数を示す図
【図５】概念モデルの冗長構造を検出するためのリストを示す図
【図６】概念モデルの表記エラーを検出するためのリストを示す図
【図７】コスト算出部におけるコスト算出の概要を示す図
【図８】システムの費用項目を示す図
【図９】開発コスト及び運用コストの算出の概要を示す図
【図１０】次期業務システム構築費の算出式を示す図
【図１１】部品種類毎のコスト換算係数を示す図
【図１２】変更種類毎のコスト換算係数を示す図
【図１３】次期システム運用保守費及び次期業務運用費の算出式を示す図
【図１４】冗長構造パターン種類毎のコスト換算係数を示す図
【図１５】クラスの親子関係を考慮したときのコスト算出の概念を示す図
【図１６】削減コスト算出部における処理を示すフローチャート
【図１７】本発明の実施例に係る概念モデル修正支援装置のハードウェア構成例を示す図
【発明を実施するための形態】
【００１３】
以下、図面を参照して本発明の実施例について説明する。
【００１４】
本発明の実施例では、ソフトウェア設計のためのデータ構造を抽象化して表現した複数のクラス図によって構成される概念モデルを用いたシステム開発において、システム移行後の評価対象の概念モデルの修正を支援する概念モデル修正支援プログラムについて説明する。なお、概念モデル修正支援プログラムに関する説明の便宜上、プログラムの各機能をコンピュータ上に実現した概念モデル修正支援装置を例に挙げて説明する。
【００１５】
図１は、本発明の実施例に係る概念モデル修正支援装置１００の機能ブロック図である。概念モデル修正支援装置１００は、入力部１０１と、概念モデル構造検出部１０３と、初期コスト算出部１０５と、削減対象クラス選定部１０７と、削減コスト算出部１０９と、出力部１１１とを有する。図２に示す本発明の実施例に係る概念モデル修正支援装置における処理を示すフローチャートを参照しつつ、各機能部について説明する。
【００１６】
入力部１０１は、システム移行前の起点となる概念モデルと、システム移行後の評価対象の概念モデルと、評価対象の概念モデルへシステムを移行させるときのコストから削減したいコストとを入力する（図２のステップＳ１０１）。以下の説明において、起点となる概念モデルを起点モデル又はＡｓＩｓ概念モデルと呼ぶ。また、評価対象の概念モデルを評価モデル又はＴｏＢｅ概念モデルと呼ぶ。概念モデルはソフトウェア設計のためのデータ構造を抽象化して表現した複数のクラス図によって構成され、例えば、オブジェクト指向分析のために用いられるＵＭＬ（Unified Modeling Language）に従って定義される。なお、削減したいコストは、割合で指定されてもよく、金額の絶対値で指定されてもよい。
【００１７】
図３は、概念モデルの定義を示す図である。図３に示す概念モデルの定義は、ＵＭＬによる定義である。概念モデルは、オブジェクトを表現するためのクラスと、オブジェクト間の関連と、クラスの継承と、対象となるモデルのまとまりを表すパッケージとで定義される。クラスには、名称、システム名、属性等の情報が含まれ、その性質（属性）も定義される。関連には、名称、多重度、関連端名称、誘導可能性、関連するクラス等の情報が含まれ、その性質も定義される。継承には、継承等の情報が含まれ、パッケージには名称等の情報が含まれる。概念モデルを表現するための個々の構成要素である情報及び性質を部品と呼び、これらの情報及び性質には必須の部品と任意選択の部品がある。
【００１８】
概念モデル構造検出部１０３は、起点モデル及び評価モデルの概念モデル構造を検出する。起点モデルから評価モデルへの移行に伴うコストの算出のため、概念モデル構造検出部１０３は、起点モデルの部品種類毎の部品数、評価モデルの部品種類毎の部品数、起点モデルから評価モデルへの変更種類毎の変更数等を検出する。起点モデル及び評価モデルの部品数は、図３に示す部品種類毎に検出される。また、起点モデルから評価モデルへの変更数は、図４に示す変更種別毎に検出される。
【００１９】
図４は、概念モデルの変更数を示す図である。変更内容が評価モデルへの部品の追加である場合、起点モデルから評価モデルへの変更数は＋１となる。変更内容が部品の名称・内容変更である場合、起点モデルから評価モデルへの変更数は０となる。変更内容が評価モデルへの部品の削除である場合、起点モデルから評価モデルへの変更数は−１となる。変更内容が部品の統合である場合、起点モデルから評価モデルへの変更数は１−（起点モデルの統合前の部品数）となる。ただし、起点モデルの統合前の部品数は２以上の整数値である。変更内容が部品の分割である場合、起点モデルから評価モデルへの変更数は（評価モデルの分割後の部品数）−１となる。ただし、評価モデルの分割後の部品数は２以上の整数値である。変更内容がパッケージをまたぐ部品の移動である場合、起点モデルから評価モデルへの変更数は０となる。なお、分割・統合・移動が発生するのは、クラス単位又はパッケージ単位だけとし、関連のレベル、継承のレベル、クラス又はパッケージが持つ情報・性質のレベルでは分割・統合・移動は発生しない。
【００２０】
また、概念モデル構造検出部１０３は、起点モデルと評価モデルの冗長構造パターン毎の冗長構造の数を検出する。概念モデルの冗長構造は、概念モデルに関して予め作成されたチェック項目に基づいて冗長構造パターン種類（チェック項目種類）毎に検出される。更に、概念モデル構造検出部１０３は、概念モデルに関して予め作成されたチェック項目に基づいて、概念モデルの表記エラーを検出する。
【００２１】
図５は、概念モデルの冗長構造を検出するためのリストを示す図である。図５は、概念モデルに記載されていると冗長な悪い表現であるという観点から定義しており、概念モデルを修正することで、より簡単な概念モデルに修正できる可能性が高い表現である。必要に応じて閾値との比較により、エラーが検出される。図５に示すチェック内容には、必ずしも冗長構造のエラーと判別できないものも含まれるが、エラーの可能性があるものとして検出される。冗長構造は運用コストに影響を与えると考えられることから、この冗長構造の数は、初期コスト算出部１０５におけるコスト算出要素の１つとなる。
【００２２】
図６は、概念モデルの表記エラーを検出するためのリストを示す図である。図６は、概念モデルに記載されていると悪い表現であるという観点から定義している。図６に示すチェック内容は、概念モデル上で表現されていれば必ず表記のエラーとして検出される。すなわち、このチェック内容に合致する表現はエラーとなるため、概念モデルの修正が必要となる。従って、表記エラーの数は、初期コスト算出部１０５におけるコスト算出要素とはならないが、表記エラーによる概念モデルの修正によって、コスト算出精度の向上が図られる。
【００２３】
初期コスト算出部１０５は、起点モデルの部品の情報と、評価モデルの部品の情報とを、所定の式に入力して、開発コスト及び運用コストを算出する（図２のステップＳ１０３）。ここで、初期コスト算出部１０５は、クラスの親子関係を考慮して、起点モデルから評価モデルへの移行に伴うコストを算出する。親クラスは、当該親クラスに属している子クラスに共通する情報を含むため、親クラスの開発コスト及び運用コストは、同じ規模の子クラスの開発コスト及び運用コストよりも大きくなる。
【００２４】
図７は、初期コスト算出部１０５におけるコスト算出の概要を示す図である。初期コスト算出部１０５は、起点モデル及び評価モデルを取得し、その差分を把握してコストを算出する。例えば、コストは、起点モデルから評価モデルへの変更要素に適切な係数を乗算したものを、変更内容毎に集計し、更に、企画・計画、要件定義、設計・構築、テスト、移行・導入、プロジェクト支援等の工程毎に集計することにより算出される。なお、図７にはコスト算出の概要の一部が記載されており、詳細については以下に説明する。
【００２５】
図８は、システムの費用項目を示す図である。システム移行に伴うコストは、現行システム運用保守費、現行業務運用費、次期業務システム構築費、次期システム運用保守費、次期業務運用費に分類することができる。現行システム運用保守費、現行業務運用費は現状調査から集計することができる。次期業務運用費は、以下に説明する次期システム運用保守費と同列での試算は可能であるが、変動幅が大きいため、算出したとしても参考値レベルとする。
【００２６】
初期コスト算出部１０５は、起点モデル及び評価モデルの情報から、設計・構築コストを算出し、設計・構築コストに適切な係数（係数ａ〜係数ｅ）を乗算することにより企画・計画、要件定義、テスト、移行・導入、プロジェクト支援のコストをそれぞれ算出する。その結果、開発（Initial）コストである次期業務システム構築費を算出することができる。例えば、「ソフトウェア開発データ白書」又は「ユーザー企業ソフトウェアメトリックス調査」により決定することができ、これらの参考資料における値を参考に経験則に基づいて、次期業務システム構築費に占める企画・計画の割合が５％、要件定義の割合が２０％、設計・構築の割合が３０％、テストの割合が３０％、移行・導入の割合が１０％、プロジェクト支援の割合が５％とし、係数ａ〜係数ｅを設定する。また、初期コスト算出部１０５は、起点モデル及び評価モデルの情報から、運用（Running）コストである次期システム運用保守費及び次期業務運用費を算出する。
【００２７】
図９は、開発コスト及び運用コストの算出の概要を示す図である。初期コスト算出部１０５は、起点モデルから評価モデルへの差分情報の中から、部品の変化を捉え、開発コストである次期業務システム構築費を算出する。例えば、クラスＣが増えてクラスＡ及びＢが変更された場合、クラスＣの増加、クラスＡ及びＢの変更、クラス間の関連の増加が差分情報の中から検出できる。その検出結果は、開発コストの算出の基礎となる。また、初期コスト算出部１０５は、起点モデルから評価モデルへの差分情報の中から、冗長構造の変化を捉え、運用コストである次期システム運用保守費及び次期業務運用費を算出する。例えば、クラスＡ及びＢがクラスＣに集約された場合、ばらばらに存在する情報が集約されたことが検出できる。この検出結果は保守性等の向上につながると考えられるため、運用コストの算出の基礎となる。
【００２８】
次に、図１０を参照して、開発コストである次期業務システム構築費について詳細に説明する。
【００２９】
次期業務システム構築費は、以下のように、基準コストに工程毎の相対コストを乗算した和として定義でき、また、工程毎に基準コストとコスト換算係数を乗算した和として定義できる。
次期業務システム構築費＝基準コスト＋Σ工程相対コスト
＝Σ工程［基準コスト×工程毎のコスト換算係数］
ここで、工程とは、図８に示す企画・計画、要件定義、設計・構築、テスト、移行・導入、プロジェクト支援を示す。基準コストは、概念モデルの要素（部品）を評価して算出する特定の工程（設計・構築）のコストである。相対コストは、基準コストに係数（図８の係数ａ〜係数ｅ）を乗算して算出する特定の工程のコストである。ここでは、設計・構築のコストを基準コストとし、相対コストは「ソフトウェア開発データ白書」又は「ユーザー企業ソフトウェアメトリックス調査」等によって公開されている統計量を使用して、基準コストに係数を乗算して算出する。
【００３０】
本発明の実施例では、基準コストを以下のように展開する。
基準コスト＝起点モデルと評価モデルの差分情報×基準コストのコスト換算係数
＝起点モデルと評価モデルの部品種類毎の部品数の差×部品種類毎のコスト換算係数＋起点モデルと評価モデルの変更種類毎の変更数×変更種類毎のコスト換算係数
＝Σ部品種類［（｜評価モデルの部品数（部品種類毎）−起点モデルの部品数（部品種類毎）｜）×コスト換算係数（部品種類毎）］＋Σ変更種類［起点モデルと評価モデルの変更数（変更種類毎）×コスト換算係数（変更種類毎）］
ここで、部品種類は図３に示す部品の種類であり、部品種類毎のコスト換算係数は、図３に示す部品の種類毎に事前に設定される。変更種類は、図４に示す変更の種類であり、変更種類毎のコスト換算係数は、図４に示す変更の種類毎に事前に設定される。上記の式において、部品数の差は絶対値として求められている。この理由は、部品を増やしても減らしても次期業務システム構築費が増加すると考えられるためである。
【００３１】
また、部品種類毎のコスト換算係数及び変更種類毎のコスト換算係数は、クラスが親クラスであるか子クラスであるかに応じて設定される。クラスの親子関係を考慮した部品種類毎のコスト換算係数を図１１に示し、クラスの親子関係を考慮した変更種類毎のコスト換算係数を図１２に示す。コスト換算係数は、親クラスの方が子クラスよりも開発コストに与える影響が大きいため、親クラスのコスト換算係数の方が子クラスのコスト換算係数よりも大きく設定される。図１１及び図１２では、親クラスのコスト換算係数は、子クラスのコスト換算係数の１．２倍に重み付けされているが、子クラスの換算係数に対する親クラスの換算係数の重み付けはどのように設定されてもよい。また、親クラスのコスト換算係数は、当該親クラスに属している子クラスのコスト換算係数に基づいて設定されてもよい。例えば、親クラスを変更（追加、編集、削除等）するときのコスト換算係数は、当該親クラスに属している子クラスの対応するコスト換算係数の和に基づいて設定されてもよい。また、部品種類毎又は変更種類毎に異なる重み付けが行われてもよい。
【００３２】
このように、開発コストである次期業務システム構築費は、起点モデルの部品種類毎の部品数と評価モデルの部品種類毎の部品数との差、及び起点モデルから評価モデルへの変更種類毎の変更数を、所定の式に入力して算出できる。
【００３３】
次に、図１３を参照して、運用コストである次期システム運用保守費及び次期業務運用費について詳細に説明する。
【００３４】
次期システム運用保守費及び次期業務運用費は、以下のように、現行システム運用保守費及び現行業務運用費にコスト増減比率を乗算して得られる。
次期システム運用保守費＝現行システム運用保守費×コスト増減比率
次期業務運用費＝現行業務運用費×コスト増減比率
本発明の実施例では、コスト増減比率を以下のように展開する。以下の式は、冗長構造の増加によりコストが増加することを示しており、冗長構造が無い場合は、最低限のコストのみが掛かることを示している。
コスト増減比率＝［評価モデルの情報量×（１＋評価モデルの冗長構造数）］／［起点モデルの情報量×（１＋起点モデルの冗長構造数）］
ここで、冗長構造数とは、クラス図の構造に関して図５に示す冗長構造パターンに合致した数である。
【００３５】
評価（又は起点）モデルの情報量、評価（又は起点）モデルの冗長構造数は以下のように展開できる。
評価（又は起点）モデルの情報量＝評価（又は起点）モデルの部品種類毎の部品数×部品種類毎のコスト換算係数
＝Σ部品種類［評価（又は起点）モデルの部品数（部品種類毎）×コスト換算係数（部品種類毎）］
評価（又は起点）モデルの冗長構造数＝評価（又は起点）モデルの冗長構造パターン種類毎のパターン数×冗長構造パターン種類毎のコスト換算係数
＝Σ冗長構造パターン種類［評価（又は起点）モデルの冗長構造パターン数（冗長構造パターン種類毎）×コスト換算係数（冗長構造パターン種類毎）］
ここで、部品種類は図３に示す部品の種類であり、部品種類毎のコスト換算係数は、図３に示す部品の種類毎に事前に設定される。冗長構造パターン種類は、図５に示すチェック項目の種類であり、冗長構造パターン種類毎のコスト換算係数は、図５に示すチェック項目の種類毎に事前に設定される。
【００３６】
また、冗長パターン種類毎のコスト換算係数は、クラスが親クラスであるか子クラスであるかに応じて設定される。クラスの親子関係を考慮した冗長パターン毎のコスト換算係数を図１４に示す。コスト換算係数は、親クラスの方が子クラスよりも運用コストに与える影響が大きいため、親クラスのコスト換算係数の方が子クラスのコスト換算係数よりも大きく設定される。図１４では、親クラスのコスト換算係数は、子クラスのコスト換算係数の１．２倍に重み付けされているが、子クラスの換算係数に対する親クラスの換算係数の重み付けはどのように設定されてもよい。また、親クラスのコスト換算係数は、当該親クラスに属している子クラスのコスト換算係数に基づいて設定されてもよい。例えば、他のクラスとの関係性が同じ親クラスが存在するときのコスト換算係数は、当該親クラスに属している子クラスの対応するコスト換算係数の和に基づいて設定されてもよい。また、冗長パターン毎に異なる重み付けが行われてもよい。
【００３７】
このように、運用コストである次期システム運用保守費及び次期業務運用費は、起点モデルの部品種類毎の部品数、評価モデルの部品種類毎の部品数、及び起点モデルと評価モデルの冗長構造パターン種類毎の冗長構造の数を、所定の式に入力して算出できる。
【００３８】
以上の手順により、起点モデルから評価モデルへの移行に伴うコストがクラス毎に算出できる。
【００３９】
削減対象クラス選定部１０７は、評価モデルを構成する各クラスに対して、入力部１０１において入力された削減したいコストに相当する削減対象のクラスの組み合わせを、クラスの親子関係を考慮して選定する（図２のステップＳ１０５）。
【００４０】
例えば、削減対象クラス選定部１０７は、初期コスト算出部１０５において算出されたクラス毎のコストを考慮して、コストの大きいクラスを優先的に選定する。ただし、親クラスの削除は、親クラスが削除された後の子クラスのコストに影響を与えるため、子クラスへの影響を考慮して選定する。
【００４１】
図１５は、クラスの親子関係を考慮したときのコスト算出の概念を示す図である。図１５（ａ）に示すように、評価モデルにおいて、子クラスＡ'及びＢ'が親クラスＣに属していることを仮定する。図１５（ｂ）に示すように、親クラスＣが削除されて、子クラスＡ'及びＢ'がクラスＡ及びＢになると、親クラスＣに存在する共通的な情報がクラスＡ及びＢに分散されるため、クラスＡ及びＢのコストは子クラスＡ'及びＢ'より増加する。ここで、親クラスＣのコストを算出するためのコスト換算係数をｐ、子クラスＡ'及びＢ'のコストを算出するためのコスト換算係数をｃと仮定する。初期コスト算出部１０５でのコスト算出において説明したように、親クラスと子クラスの規模が同じであれば、親クラスの重要度を考慮してｐ＞ｃである。親クラス削除後のクラスＡ及びＢのコスト換算係数はｐ＋ｃと表すことができ、例えば、ｐ＝１０、ｃ＝５とした場合、親クラス削除前のコスト換算係数の合計は２０であり、親クラス削除後のコスト換算係数の合計は３０である。すなわち、親クラスＣを削除することにより、クラスＡ及びＢのコストが増大する。以下の説明では、親クラス削除後のコスト換算係数をｐ＋ｃとして説明するが、クラスＡ及びＢのコスト換算係数は、ｐ＋ｃに限定されず、子クラスのコスト換算係数ｃに親クラスのコスト換算係数ｐを反映したものであれば、例えばｐ＊α＋ｃ（αは定数）が用いられてもよく、ｐ／β＋ｃ（βは削除する親クラスに属する子クラスの数）が用いられてもよく、ｐ＊ｃが用いられてもよい。
【００４２】
削減コスト算出部１０９は、削減対象クラス選定部１０７により選定された削減対象のクラス毎に、削減対象のクラスが削除されたときのコスト削減量を、削減対象のクラスの親子関係に基づいて算出する（図２のステップＳ１０７）。削減コスト算出部１０９は、削減対象のクラスが子クラスである場合には、削減コスト算出部１０９において子クラスのコスト換算係数を用いて算出したコストがコスト削減量として算出できる。一方、図１５を参照して説明したように、削減対象のクラスが親クラスである場合には、初期コスト算出部１０５において親クラスのコスト換算係数を用いて算出したコストがコスト削減量と一致するとは限らない。例えば、削減コスト算出部１０９は、親クラスＣのコスト換算係数ｐを用いて算出した親クラスＣのコストから、子クラスＡ'及びＢ'のコスト換算係数ｃが親クラスＣの削除後にコスト換算係数ｐ＋ｃに変わることを考慮してコスト削減量を算出する。
【００４３】
図１６は、削減コスト算出部１０９における処理を示すフローチャートである。削減コスト算出部１０９は、コスト削減量を算出するときに、親クラスが削除されているか否かを判断する（ステップＳ２０１）。親クラスが削除されていない場合（ステップＳ２０１：ＮＯ）、子クラスのコスト換算係数をｃと設定する（ステップＳ２０３）。すなわち、親クラスＣが削除されていない場合の子クラスＡ'及びＢ'のコストはコスト換算係数ｃを用いて算出したコストである。一方、親クラスが削除されている場合（ステップＳ２０１：ＹＥＳ）、子クラスのコスト換算係数をｐ＋ｃと設定する（ステップＳ２０５）。すなわち、親クラスＣの削除後のクラスＡ及びＢのコストは、初期コスト算出部１０５における開発コスト及び運用コストの算出式においてコスト換算係数ｐ＋ｃを用いて算出できる。削減コスト算出部１０９は、設定したコスト換算係数を用いてコスト削減量を算出する（ステップＳ２０７）。なお、子クラスＡ'及びＢ'がクラスＡ及びＢになることにより、部品数、変更数、冗長構造の数等が変化するが、このような変化はコスト換算係数がｃからｐ＋ｃに変わることでコスト算出に反映されるため、必ずしも部品数、変更数、冗長構造の数等の変化を算出し直して初期コスト算出部１０５における開発コスト及び運用コストの算出式に当てはめなくてもよい。
【００４４】
このように、削減コスト算出部１０９は、削減対象のクラスが親クラスであるか子クラスであるかに応じて設定されたコスト換算係数を用いて、コスト削減量を算出するが、削減対象のクラスが親クラスである場合、依存関係のある子クラスのコスト換算係数を高くして、コスト削減量を算出する。
【００４５】
削減対象クラス選定部１０７は、削減コスト算出部１０９において算出されたコスト削減量と、入力部１０１において入力された削減したいコストとを比較し、これらの差が閾値の範囲内である場合（図２のステップＳ１０９：ＹＥＳ）、削減対象のクラスの選定を終了する。一方、削減コスト算出部１０９において算出されたコスト削減量と、入力部１０１において入力された削減したいコストとの差が閾値の範囲内より大きくなる場合（図２のステップＳ１０９：ＮＯ）、削減対象クラス選定部１０７は、削減対象のクラスの組み合わせを選定し直す（図２のステップＳ１０５）。
【００４６】
最後に、出力部１１１は、削減対象クラス選定部１０７において選定された削減対象のクラスの組み合わせを出力する（図２のステップＳ１１１）。出力部１１１は、削減対象のクラスの組み合わせが削除されたときのコスト削減量も出力してもよい。
【００４７】
＜本発明の実施例の効果＞
従来のコスト算出法は、概念モデルをインプットとしたコスト算出ではないため、ある程度実装する機能が明確になるまでコストの算出はできなかった。また、コストを算出したときに想定コストより大きくなった場合に、どの部分を修正すれば想定コストに近づくかを把握することができなかった。本発明の実施例によれば、クラスの親子関係によってクラスの重要度に応じて削減したいコストに合った修正すべきクラスの組み合わせを提示することが可能になる。そして、初回の設計後に、必要なコスト削減量に合ったクラスの修正を柔軟に行うことが可能になり、コストの範囲内で最大限品質の高いソフトウェア設計を行うことが可能となる。
【００４８】
また、親クラスと子クラスとで重み付けを変えて、クラスの継承関係を考慮してコストを算出することが可能になり、正確な開発を支援することが可能になる。
【００４９】
また、削減対象のクラスのコストのみを考慮して全体のコスト削減量を算出しようとすると、親クラスの削減が子クラスに開発コストが振り分けられ、親クラス削減後の改修コストが増大し、正確なコスト削減幅の範囲内での開発を阻害していたが、親クラス削除後の子クラスのコスト換算係数を高くすることで、正確なコスト把握が可能になり、開発コストの範囲で最大限の品質を確保したプログラム開発を推進することが可能となる。
【００５０】
＜ハードウェア構成例＞
図１７に、本発明の実施例に係る概念モデル修正支援装置１００のハードウェア構成例を示す。概念モデル修正支援装置１００は、ＣＰＵ（Central Processing Unit）１５１等のプロセッサ、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）等のメモリ装置１５２、ハードディスク等の記憶装置１５３等から構成されたコンピュータでもよい。例えば、概念モデル修正支援装置１００の機能及び処理は、記憶装置１５３又はメモリ装置１５２に格納されているデータやプログラムをＣＰＵ１５１が実行することによって実現される。また、概念モデル修正支援装置１００に必要な情報は、入出力インタフェース装置１５４から入力され、概念モデル修正支援装置１００において求められた結果は、入出力インタフェース装置１５４から出力されてもよい。
【００５１】
＜補足＞
説明の便宜上、本発明の実施例に係る概念モデル修正支援装置は機能的なブロック図を用いて説明しているが、本発明の実施例に係る概念モデル修正支援装置は、ハードウェア、ソフトウェア又はそれらの組み合わせで実現されてもよい。例えば、本発明の実施例は、コンピュータに対して本発明の実施例に係る概念モデル修正支援装置の機能を実現させるプログラム、コンピュータに対して本発明の実施例に係る方法の各手順を実行させるプログラム等により、実現されてもよい。また、各機能部が必要に応じて組み合わせて使用されてもよい。また、本発明の実施例に係る方法は、実施例に示す順序と異なる順序で実施されてもよい。
【００５２】
以上、概念モデルを入力としてシステム移行に伴うコストを算出するための手法について説明したが、本発明は、上記の実施例に限定されることなく、特許請求の範囲内において、種々の変更・応用が可能である。
【符号の説明】
【００５３】
１００  概念モデル修正支援装置
１０１  入力部
１０３  概念モデル構造検出部
１０５  初期コスト算出部
１０７  削減対象クラス選定部
１０９  削減コスト算出部
１１１  出力部
１５１  ＣＰＵ
１５２  メモリ装置
１５３  記憶装置
１５４  入出力インタフェース装置
【図１】
2018085067.tif 000003
【図２】
2018085067.tif 000004
【図３】
2018085067.tif 000005
【図４】
2018085067.tif 000006
【図５】
2018085067.tif 000007
【図６】
2018085067.tif 000008
【図７】
2018085067.tif 000009
【図８】
2018085067.tif 000010
【図９】
2018085067.tif 000011
【図１０】
2018085067.tif 000012
【図１１】
2018085067.tif 000013
【図１２】
2018085067.tif 000014
【図１３】
2018085067.tif 000015
【図１４】
2018085067.tif 000016
【図１５】
2018085067.tif 000017
【図１６】
2018085067.tif 000018
【図１７】
2018085067.tif 000019