JP5449438B2 - ソフトウェア資産再利用支援装置およびソフトウェア資産再利用支援プログラム - Google Patents

Description

本発明の実施形態は、ソフトウェア資産再利用支援装置およびソフトウェア資産再利用支援プログラムに関する

ソフトウェア資産を計画的に再利用する開発方法として、プロダクトライン型開発がある。プロダクトライン型開発とは、予め定義した製品系列の情報であるロードマップから、製品系列を通じた共通部分と製品ごとに拡張／選択する可変部分を定義し、共通部分を計画的に開発することで、ソフトウェア資産の再利用性の向上を目指す開発方法である。

製品系列の共通部分、可変部分を定義する際、フィーチャーモデルを用いて分析を行うことがある。「フィーチャーモデル」とは、フィーチャーと呼ばれる対象製品の関心事を定めるものである。ここで、「フィーチャー」とは、対象製品との関係性によって「必須、排他、選択（オプション）」の３つに分類して階層的に整理され、製品系列の特徴を把握するために用いられる。なお、フィーチャーは機能要件だけでなく、例えば品質に関わる特性である非機能要件も含む。

フィーチャーモデルにおいて、必須のフィーチャーが共通部分となり、排他および選択フィーチャーが可変部分となる。したがって、フィーチャーモデルを高精度で構築できれば、ソフトウェア製品開発においてのソフトウェア資産の再利用性向上を期待できる。

しかしながら、フィーチャーモデルを低精度でしか構築できない場合は、再利用性の向上は期待できない。すなわち、製品系列に基づいたソフトウェア開発で再利用性を向上させるためには、フィーチャーモデルを高精度で構築する必要がある。

上述のように、フィーチャーモデルの構築が製品を構築していく際に用いるロードマップに基づいて行なわれる場合、高精度なフィーチャーモデルを構築するためには、このロードマップの精度を高くして作る必要がある。しかしながら、ロードマップを高精度に作成することは一般的に非常に困難である。

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

本発明が解決しようとする課題は、製品毎に設計される仕様データからフィーチャーモデル候補を生成することで、フィーチャーモデルを高精度で構築できるソフトウェア資産再利用支援装置およびソフトウェア資産再利用支援プログラムを提供することである。

実施形態のソフトウェア資産再利用支援装置は、製品系列と当該製品系列に属する製品毎の仕様とを定義する仕様データが入力されるユーザインターフェース部と、製品系列と前記仕様データと当該仕様データの識別子である仕様ＩＤとを関連付けて記憶する仕様データ記憶部と、前記ユーザインターフェース部に入力された仕様データに基づいて、前記仕様データ記憶部から、前記仕様ＩＤに関連付けられている前記仕様データを取得する仕様データ取得部と、前記仕様データ取得部によって取得された仕様データと前記ユーザインターフェース部によって入力された仕様データとが合致するか否かを検索し、合致する場合に前記仕様データ取得部によって取得された仕様データの仕様ＩＤを前記ユーザインターフェース部によって入力された仕様データの再利用ＩＤとして設定する再利用ＩＤ設定部と、前記仕様データ記憶部に記憶された前記仕様データと前記製品系列に属する製品群との関連性を分析するルールを定めるパターン情報を記憶するパターン記憶部と、前記仕様データ記憶部に記憶された前記仕様データと当該仕様データの前記仕様ＩＤと前記再利用ＩＤ、および、パターン記憶部に記憶された前記パターン情報を用いて、前記パターン情報について、前記仕様データ記憶部に記憶された前記仕様データが、前記製品系列に属する全製品の仕様データに共通に含まれるか否かを示す条件、および、前記仕様データ記憶部に記憶された前記仕様データが、前記製品系列に属する全製品の仕様データに共通に含まれない場合、当該仕様データが属する製品系列の他の仕様データに、前記仕様データと排他的な仕様データがあるか否かを示す条件、に着目し、前記製品系列における前記仕様データの関連性を判定する関連性判定部と、前記関連性判定部による判定結果に基づいてフィーチャーモデル候補を構築するフィーチャーモデル候補構築部と、を備える。

第１実施形態のソフトウェア資産再利用支援装置に係る全体構成を示す図。 第１実施形態のソフトウェア資産再利用支援装置に係る機能構成を示す図。 第１実施形態のソフトウェア資産再利用支援装置に係る仕様データ登録処理の一例を示すフローチャート。 第１実施形態のソフトウェア資産再利用支援装置に係る仕様データＤＢの一例を示す図。 第１実施形態のソフトウェア資産再利用支援装置に係る仕様データ取得処理の一例を示すフローチャート。 第１実施形態のソフトウェア資産再利用支援装置に係る仕様データの一例を示す図。 第１実施形態のソフトウェア資産再利用支援装置に係るフィーチャーモデル候補構築処理の一例を示すフローチャート。 第１実施形態のソフトウェア資産再利用支援装置に係るパターン情報の一例を示す図。 第１実施形態のソフトウェア資産再利用支援装置に係るフィーチャー抽出のロジックの一例を示す図。 第１実施形態のソフトウェア資産再利用支援装置に係るフィーチャーモデル候補の一例を示す図。 第２実施形態のソフトウェア資産再利用支援装置に係る仕様データの一例を示す図。 第２実施形態のソフトウェア資産再利用支援装置に係る仕様データの一例を示す図。 第２実施形態のソフトウェア資産再利用支援装置に係る仕様データの一例を示す図。 第２実施形態のソフトウェア資産再利用支援装置に係るフィーチャーモデル候補構築処理の一例を示すフローチャート。 第２実施形態のソフトウェア資産再利用支援装置に係るフィーチャーモデル候補の一例を示す図。 第２実施形態のソフトウェア資産再利用支援装置に係るフィーチャーモデル候補の一例を示す図。 第２実施形態のソフトウェア資産再利用支援装置に係るフィーチャーモデル候補の一例を示す図。

以下、実施形態のソフトウェア資産再利用支援装置について図面を参照して説明する。なお、以下の各装置は、装置毎に、ハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は記憶媒体から対応する装置のコンピュータにインストールされ、対応する装置の機能を実現させるためのプログラムが用いられる。

（第１実施形態）
図１乃至図１０を参照して、本発明の第１実施形態に係るソフトウェア資産再利用支援装置１０について説明する。

図１は、本発明の第１実施形態に係るソフトウェア資産再利用支援装置１０の構成を示す模式図である。このソフトウェア資産再利用支援装置１０は、主記憶装置１１、キーボード１２、マウス１３、中央演算装置１４およびディスプレイ装置１５を備えている。なお、ソフトウェア資産再利用支援装置１０は例えば、本実施形態に係るソフトウェア資産再利用支援プログラムが適用された計算機によって実現される。

記憶装置１１は、中央演算装置１４から読出／書込み可能な記憶装置であり、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）である。記憶装置１１は、あらかじめソフトウェア資産再利用プログラムが記憶されている。

キーボード１２およびマウス１３は、通常の入力装置であり、例えば、ユーザの操作により、データ又は命令からなる各種情報を中央演算装置１４に入力する機能をもっている。

中央演算装置１４は、通常のＣＰＵであり、例えば、記憶装置１１に記憶されたソフトウェア資産再利用プログラムを実行する機能と、キーボード１２又はマウス１３から入力される情報に基づいて各プログラムの実行を制御する機能と、実行結果等をディスプレイ装置１５に出力する機能とをもっている。

ディスプレイ装置１５は、通常の表示装置であり、例えば、編集中の各アーキテクチャモデルやフィーチャーモデル等を表示して可視化し、他にも中央演算装置１４から出力された情報を表示する機能をもっている。

図２を参照して、以上のように構成されたソフトウェア資産再利用支援装置１０の機能構成について説明する。

ソフトウェア資産再利用支援装置１０は、ユーザインターフェース部２１、制御部２２、仕様データ登録部２３、仕様データＩＤ付与部２４、仕様データＤＢ（データベース）２５、仕様データ取得部２６、再利用ＩＤ設定部２７、フィーチャーモデル候補構築部２８、仕様データ関連性分析部２９、およびパターンＤＢ３０を備える。

ユーザインターフェース部２１は、キーボート１２、マウス１３、およびディスプレイ１５で実現され、ソフトウェアの設計者であるユーザの入力情報や指示情報を受け付ける。

制御部２２は、ソフトウェア資産再利用支援装置１０の各機能を制御する。

仕様データ登録部２３は、仕様データＩＤ付与部２４を備える。仕様データ登録部２３は、制御部２２から、ユーザインターフェース部２１を介して入力される仕様データを含む仕様データ登録要求を受信すると、後述する仕様データＤＢ２５に仕様データを登録する。

なお、仕様データは、製品の仕様を示すデータであり、例えば要件定義や設計などの各工程で決定するべき情報を定義した情報（メタモデル）である。すなわち、仕様データは、作成するソフトウェアに必要な機能要件や、品質などの非機能要件を定義した情報である。

仕様データＩＤ付与部２４は、仕様データ登録部２３が受信した仕様データに仕様ＩＤを付与する。すなわち、仕様データ登録部２３は、仕様データ登録要求に含まれる仕様データと仕様データＩＤ付与部２４が付与した仕様ＩＤとを関連付けて仕様データＤＢ２５に登録する。

仕様データ取得部２６は、再利用ＩＤ設定部２７を備え、ユーザがユーザインターフェース部２１を介して指示した条件に合致する仕様データを仕様データＤＢ２５から取得する。

再利用ＩＤ設定部２７は、仕様データ取得部２６が取得した仕様データに、再利用ＩＤを設定する再利用ＩＤ設定処理を行う。再利用ＩＤ設定処理については後述する。
フィーチャーモデル候補構築部２８は、仕様データ関連性分析部２９を備える。フィーチャーモデル候補構築部２８は、ユーザがユーザインターフェース部２１を介して入力したフィーチャーモデル候補要求に基づいて仕様データＤＢ２５から仕様データを取得し、取得した仕様データと、パターンＤＢ３０に記憶された、仕様データと当該仕様データと製品系列との関連性を分析するルールを定めるパターン情報に基づいてフィーチャーモデル候補を構築する。

フィーチャーは、機能や品質要求など、対象製品の特性を表現したものであり、要件を管理する単位の１つである。フィーチャーモデルはある製品系列を構成するフィーチャーを必須、オプション、排他、選択といった当該製品系列との関連性とともに表現したものである。

仕様データ関連性分析部２９は、ユーザインターフェース部２１から入力された製品系列情報に基づいて仕様データＤＢ２５から仕様データを抽出する。ここで抽出された各仕様データは、フィーチャーモデル候補構築部２８が構築するフィーチャーモデル候補における各フィーチャーとなる。

また、仕様データ関連性分析部２９、パターンＤＢ３０に記憶されたパターン情報に基づいて、抽出したフィーチャーと製品系列との関連性を分析する。なお、製品系列との関連性は例えば「必須」、「排他」、「選択」である。つまり、「関連性」とは、フィーチャーモデル構築対象の製品系列に対して、分析対象の仕様データが使用されるか否かで判断される概念である。

「必須」とは、フィーチャーモデル構築対象の製品系列において、分析対象の仕様データが製品系列に含まれる全ての製品に含まれることである。なお、全ての製品ではなく、所定の閾値以上の製品数に含まれている場合に「必須」とすることも可能である。

「排他」とは、フィーチャーモデル構築対象の製品系列において、分析対象の仕様データが使用されない製品があり、かつ分析対象の仕様データと排他的に使用される他の仕様データがあることである。

「選択」とは、フィーチャーモデル構築対象の製品系列において、分析対象の仕様データが使用されない製品があることである。

以下、製品系列との関連性が「必須」のフィーチャーを必須フィーチャー、「排他」のフィーチャーを排他フィーチャー、「選択」のフィーチャーを選択フィーチャーという。

すなわち、必須フィーチャーは、製品系列で共通に利用する仕様データであり、選択フィーチャーは、製品ごとに利用するか否かの条件が異なる仕様データである。選択フィーチャーのうち、他の仕様データと排他的に製品に利用される仕様データは排他フィーチャーである。

パターンＤＢ３０に格納されるパターンのうち、必須フィーチャーを抽出するパターンを必須フィーチャー抽出パターンという。同様に、排他フィーチャーを抽出するパターンを排他フィーチャー抽出パターンといい、選択フィーチャーを抽出するパターンを選択フィーチャー抽出パターンという。

上記のように構成されたソフトウェア資産再利用支援装置１０は、以下の３つの処理を行う。

１．仕様データ登録処理
２．仕様データ取得処理
３．フィーチャーモデル候補構築処理
以下、図３乃至図１０を参照して、本実施形態のソフトウェア資産再利用支援装置１０が行なう処理について説明する。なお、本実施形態では、携帯電話の簡単な機能仕様データについて、予め定義したパターンを適用させてフィーチャーモデルを構築する例について説明する。

図３は、ソフトウェア資産再利用支援装置１０が行なう仕様データ登録処理の一例を示すフローチャートである。ここでは、後述する仕様データ取得処理において再利用される仕様データを登録する。

まず、ユーザがユーザインターフェース部２１を介して仕様データと、当該仕様データの登録要求を入力する（ステップＳ１１）。仕様データ登録要求は、例えばユーザがユーザインターフェース部２１を介して仕様データを入力した後に、ユーザインターフェース部２１に表示された登録ボタンを押すと入力される。

制御部２２はユーザインターフェース部２１が受信した仕様データと仕様データ登録要求を仕様データ登録部２３に送信する（ステップＳ１２）。

仕様データ登録部２３が仕様データと仕様データ登録要求を受信すると（ステップＳ１３）、仕様データＩＤ付与部２４は、受信した仕様データに当該仕様データを特定するための識別子である仕様ＩＤを付与する（ステップＳ１４）。仕様データ登録部２３は、仕様データＩＤ付与部２４が付与した仕様ＩＤを含む仕様データを仕様データＤＢ２５に登録する（ステップＳ１５）。これにより仕様データ登録処理は終了する。

ここで、図４を参照して、仕様データ登録処理によって仕様データが登録された仕様データＤＢ２５について説明する。図４に示すように、本実施形態の仕様データＤＢ２５は製品１に関する仕様データ２５ａＡが登録されたとする。

図４に示すように、仕様データＤＢ２５は、製品１の仕様データテーブル２５ａＡを備える。

仕様データテーブル２５ａＡは、仕様ＩＤ、機能ＩＤ、機能名、概要、入力データＩＤ、出力データＩＤ、再利用ＩＤを項目として備える。なお、新規登録の時点では再利用ＩＤは空である。

また、仕様データテーブル２５ａＡは製品系列名２５１をタグとして備える。なお、製品系列名は仕様データテーブル２５ａＡの項目に加えてもよい。本実施形態の仕様データテーブル２５ａＡは全て、製品系列は携帯端末である。

仕様データテーブル２５ａＡの項目である仕様ＩＤは、ステップＳ１４において仕様データＩＤ付与部２４が付与した、各仕様データを特定するための識別子が格納される。

機能ＩＤは、仕様データの機能毎に付与される識別子である。機能名は、仕様データに含まれる各機能の名称である。

概要は、当該仕様データを実現する方法など、仕様データに関する説明文が格納される。

入力データＩＤは各機能において入力されるデータがある場合にそのデータを識別するためのＩＤが格納される。出力データＩＤは、各機能において出力されるデータがある場合にそのデータを識別するためのＩＤが格納される。再利用ＩＤは、後述する再利用ＩＤ設定部２７が再利用ＩＤを設定した場合に格納される。

図４の仕様データテーブル２５ａＡに示すように製品１は、「通話」、「メール」、「キー入力」、「カメラ」を機能としてもつ。

続いて、図５を参照してソフトウェア資産再利用支援装置１０が行なう仕様データ取得処理の一例について説明する。仕様データ取得処理では再利用可能な仕様データを取得する。

ユーザがユーザインターフェース部２１を介して作成対象の製品に関する仕様データを入力する（ステップＳ２１）。このとき入力される仕様データは製品系列名や機能名などが含まれる。また、このときユーザはユーザインターフェース部２１を介して仕様データを入力した後に、例えばユーザインターフェース部２１に表示された「取得」ボタンを押すとする。

ユーザがユーザインターフェース部２１の「取得」ボタンを押して仕様データを入力すると、制御部２２は入力された仕様データを含む仕様データ取得要求を仕様データ取得部２６に送信する（ステップＳ２２）。

仕様データ取得部２６は、仕様データ取得要求に含まれる仕様データに合致する仕様データが仕様データＤＢ２５にあるか否か検索する（ステップＳ２３）。仕様データ取得要求に含まれる仕様データに合致する仕様データが仕様データＤＢ２５にあるか否かは、例えば仕様データ取得要求に含まれる仕様データの機能名と、仕様データＤＢ２５に記憶された仕様データの機能名とが一致するか否かによって判定される。もしくは、機能名が類似しているか否かによって判定しても良い。

仕様データＤＢ２５に仕様データ取得要求に合致する仕様データがある場合（ステップＳ２３がＹｅｓ）、仕様データ取得部２６は仕様データ取得要求に合致する仕様データを取得する（ステップＳ２４）。

再利用ＩＤ設定部２７は、仕様データ取得部２６が取得した仕様データの仕様ＩＤを、ステップＳ２１で入力された仕様データの再利用ＩＤとして設定する（ステップＳ２５）。

再利用ＩＤが設定された仕様データは、制御部２２を介してユーザインターフェース部２１に送信され、ユーザインターフェース部２１は当該再利用ＩＤが設定された仕様データを表示する（ステップＳ２６）。また、ステップＳ２６で、制御部２２が表示された仕様データを仕様データＤＢ２５に登録してもよい。これにより仕様データ取得処理は終了する。

仕様データＤＢ２５に仕様データ取得要求に含まれる仕様データに合致する仕様データがない場合（ステップＳ２３がＮｏ）、ステップＳ２４〜ステップＳ２６の処理を行わず、仕様データ取得部２６は仕様データ取得処理を終了する。

ここで、以下に示す製品２と製品３において仕様データ取得処理を行う場合について説明する。製品２と製品３は、製品１、製品２、製品３と順番に開発されるものである。製品２の仕様データを開発する際に、製品１の仕様データの一部を再利用し、製品３の仕様を開発する際に、製品２と製品１の仕様データの一部を再利用したとする。

図６に、仕様データ取得処理の結果、作成される製品２と製品３の仕様データの一例と示す。

図６の仕様データテーブル２５ａＢに示すように、製品２は、「通話」、「メール」、「キー入力」、「ＩＣカード」を機能としてもつ。製品２の機能のうち、既存である製品１の仕様データを再利用した仕様データは、再利用ＩＤが格納されている「通話」、「メール」、「キー入力」である。

また、図６の仕様データテーブル２５ａＣに示すように、製品３は「通話」、「メール」、「タッチパネル入力」、「カメラ」、「ＧＰＳ」を機能としてもつ。製品３の機能のうち、既存である製品１の仕様データを再利用した仕様データは、再利用ＩＤが格納されている「通話」、「メール」（以上、製品２）、「カメラ」（製品１）である。

「キー入力」機能と「タッチパネル入力」機能は、共に入力データと出力データが同一であるものとする。すなわち、「キー入力」機能と「タッチパネル入力」機能は再利用した仕様データではないが、関連性の深い仕様データと考える。

なお、仕様データ取得処理のステップＳ２４において、仕様データＤＢ２５に記憶された仕様データから複数の仕様データが取得された場合、全部取得してもよいし、最も新しい仕様データのみ取得しても良い。

図７を参照して、ソフトウェア資産再利用支援装置１０が、図６に示す仕様データ２５ａＡ、２５ａＢ、２５ａＣに対して行なうフィーチャーモデル候補構築処理の一例について説明する。

ユーザがユーザインターフェース部２１を介しフィーチャーモデル候補構築対象の製品系列名を含むフィーチャーモデル候補構築要求を入力する（ステップＳ３１）。フィーチャーモデル候補構築要求は、例えばユーザがユーザインターフェース部２１を介して製品系列名を入力した後に、ユーザインターフェース部２１表示されたフィーチャーモデル候補構築ボタンを押すと入力される。ここでは、製品系列名として「携帯端末」が入力される。

ユーザインターフェース部２１から製品系列名を含むフィーチャーモデル候補構築要求が入力されると、制御部２２は入力されたフィーチャーモデル候補構築要求をフィーチャーモデル候補構築部２８に送信する（ステップＳ３２）。

フィーチャーモデル候補構築部２８は、フィーチャーモデル候補構築対象の製品系列名に基づいて仕様データＤＢ２５から仕様データを取得する（ステップＳ３３）。すなわち、仕様データ２５ａＡ、２５ａＢ、２５ａＣが取得される。

フィーチャーモデル候補構築部２８の仕様データ関連性分析部２９は、フィーチャーモデル候補構築部２８が取得した仕様データと、フィーチャーモデル候補構築対象の製品系列との関連性を分析する（ステップＳ３４）。

フィーチャーモデル候補構築部２８が取得した仕様データにおいて、仕様データ関連性分析部２９がフィーチャーモデル候補構築対象の製品系列との関連性を分析していない仕様データが存在する場合（ステップＳ３４がＮｏ）、仕様データ関連性分析部２９はそのうちの１つの仕様データを選択し、当該仕様データはパターンＤＢ３０に格納されたパターン情報のうち、必須フィーチャー抽出パターンの抽出条件と合致するか否か判定する（ステップＳ３５）。

図８に、パターンＤＢ３０に記憶されるパターン情報の一例を示す。図８に示すようにパターンＤＢ３０には、必須フィーチャー抽出パターン３０ａＡ、排他フィーチャー抽出パターン３０ａＢ、選択フィーチャー抽出パターン３０ａＣが格納されている。

当該仕様データが必須フィーチャー抽出パターン３０ａＡの抽出条件と合致する場合（ステップＳ３５がＹｅｓ）、仕様データ関連性分析部２９は当該仕様データを必須フィーチャーとする（ステップＳ３６）。その後ステップＳ３４に戻り処理を繰り返す。

当該仕様データが必須フィーチャー抽出パターン３０ａＡの抽出条件と合致しない場合（ステップＳ３５がＮｏ）、仕様データ関連性分析部２９は、当該仕様データはパターンＤＢ３０に格納されたパターン情報のうち、排他フィーチャー抽出パターン３０ａＢの抽出条件と合致するか否か判定する（ステップＳ３６）。

排他フィーチャー抽出パターン３０ａＡの抽出条件と合致する場合（ステップＳ３７がＹｅｓ）、仕様データ関連性分析部２９は当該仕様データを排他フィーチャーとする（ステップＳ３８）。その後ステップＳ３４に戻り処理を繰り返す。

排他フィーチャー抽出パターン３０ａＡの抽出条件と合致しない場合（ステップＳ３７がＮｏ）、仕様データ関連性分析部２９は、当該仕様データを選択フィーチャーとする（ステップＳ３９）。その後ステップＳ３４に戻り処理を繰り返す。

なお、ステップＳ３９で仕様データ関連性分析部２９は、当該仕様データはパターンＤＢ３０に格納されたパターン情報のうち、選択フィーチャー抽出パターン３０ａＣの抽出条件と合致するか否か判定してもよい。

図９にフィーチャー抽出のロジックの一例として、必須フィーチャー抽出パターン３０ａＡに基づいて、仕様データから必須フィーチャーを抽出するロジックを示す。

図７の説明に戻る。フィーチャーモデル候補構築部２８が取得した全ての仕様データにおいて、仕様データ関連性分析部２９がフィーチャーモデル候補構築対象の製品系列との関連性を分析している場合（ステップＳ３４がＹｅｓ）、フィーチャーモデル候補構築部２８が、ステップＳ３３で取得した仕様データと、仕様データ関連性分析部２９による分析結果に基づいてフィーチャーモデル候補を構築する（ステップＳ４０）。これによりフィーチャーモデル候補構築処理を終了する。

すなわち、フィーチャーモデル候補構築処理では、仕様データＤＢ２５に蓄積した仕様データからフィーチャーモデル候補を構築する。

ここで、ステップＳ３５からステップＳ３９において仕様データ２５ａＡ〜仕様データ２５ａＣに対してパターン３０ａＡ〜３０ａＣを適用してフィーチャーを抽出する際の処理について具体的に説明する。

まず、ステップＳ３５において、仕様データ関連性分析部２９は、製品３において再利用された仕様データを仕様データ２５ａＣから抽出する。再利用された仕様データは再利用ＩＤの有無で判断する。このとき抽出される仕様データは、仕様ＩＤ：３１１（再利用ＩＤ：２１１）、仕様ＩＤ：３１２（再利用ＩＤ：２１２）、仕様ＩＤ：３１４（再利用ＩＤ：１１４）である。

続いて仕様データ関連性分析部２９は、製品２で再利用した仕様データを仕様データ２５ａＢから抽出する。このとき抽出される仕様データは、仕様ＩＤ：３１１（再利用ＩＤ：１１１）、仕様ＩＤ：３１２（再利用ＩＤ：１１２）、仕様ＩＤ：２１３（再利用ＩＤ：１１３）である。

製品２と製品３の両方で再利用されている仕様データが「必須」と判定される。具体的に言うと、仕様ＩＤ：３１１（再利用ＩＤ：２１１、１１１）、仕様ＩＤ：３１２（再利用ＩＤ：２１２、１１２）
続いてステップＳ３６において仕様データ関連性分析部２９は、ステップＳ３５において抽出されなかった仕様データを抽出する。具体的には、図６に示す仕様データのうち、仕様ＩＤ：３１３、仕様ＩＤ：３１４（再利用ＩＤ：１１４）、仕様ＩＤ：３１５、仕様ＩＤ：２１３（再利用ＩＤ：１１３）、仕様ＩＤ：２１４、仕様ＩＤ：１１４の仕様データである。

これらの仕様データにおいて、入出力データが同じであるが、異なる仕様を示す仕様データを抽出候補とする。ここでは、図６の仕様ＩＤ：３１３と仕様ＩＤ：２１３（再利用ＩＤ：１１３）の仕様データが抽出候補である。また、「入出力データが同じであるが、異なる仕様」とは、入出力データが同じであるが、概要もしくは機能名が異なる仕様データのことである。

仕様データＤＢ２５に格納される仕様データ２５ａＡ〜２５ａＣのそれぞれに、抽出した仕様データのいずれか１つが存在する場合、当該抽出した仕様データは排他と判定される。ここでは、仕様ＩＤ：３１３と仕様ＩＤ：２１３（再利用ＩＤ：１１３）の仕様データは、仕様データ２５ａＡ〜２５ａＣにおいていずれかが存在するため、排他であると判定される。このとき、仕様データ関連性分析部２９は、「排他」の要素を束ねるフィーチャーの抽出を行なう。具体的には、仕様ＩＤ：３１３と仕様ＩＤ：２１３（再利用ＩＤ：１１３）の機能名の共通部分を抽出した「入力」をフィーチャーとする。

続いて、ステップＳ３７では、仕様データ関連性分析部２９は、ステップＳ３５において抽出されなかった仕様データのうち、ステップＳ３６で排他と判定されなかった仕様データを抽出する。具体的には、仕様ＩＤ：３１４（再利用ＩＤ：１１４）、仕様ＩＤ：３１５、仕様ＩＤ：２１４、仕様ＩＤ：１１４の仕様データを抽出し、これらを「選択」と判定する。

図１０に、仕様データ２５ａＡ〜２５ａＣから抽出されたフィーチャーとフィーチャーの関連性に基づいて、フィーチャーモデル候補構築部２８によって構築されたフィーチャーモデル候補の例を示す。図１０には、必須フィーチャーに黒丸、選択フィーチャーに白丸をそれぞれ表示し、排他フィーチャーは、排他関係にある他のフィーチャーとの間を曲線でつないでいる。

図１０に示す、フィーチャーモデル候補から以下の内容がわかる。

１．「通話」、「メール」、「入力」は必須機能。

２．「入力フィーチャー」において、「キー入力」と「タッチパネル入力」は排他の関係。

３．「ＩＣカード」、「ＧＰＳ」、「カメラ」機能は、選択の関係。

また、ユーザは、ユーザインターフェース部２１に表示されたフィーチャーモデル候補を修正（補正）して、フィーチャーモデルを完成させる。なお、フィーチャーモデル候補構築部３８が作成したフィーチャーモデル候補を自動的にフィーチャーモデルとして決定してもよい。

上述のように、本実施形態のソフトウェア資産再利用支援装置１０によると、仕様データに基づいてフィーチャーモデル候補を生成することが可能であるため、フィーチャーモデル構築のコスト軽減が期待できる。また、同一の製品系列における異なる製品の仕様データを分析することで、従来のフィーチャーモデルの構築方法と比較してフィーチャーモデルの確度を向上することができる。

（第２実施形態）
以下、本実施形態のソフトウェア資産再利用支援装置について図面を参照して説明する。なお、第１実施形態と同一の構成には同一の符号を付与し、説明は省略する。

本実施形態では、階層的に定義されている仕様データからフィーチャーモデルを構築する場合のソフトウェア資産再利用支援装置１０の動作について説明する。

図１１に、本実施形態における仕様データＤＢ２５に登録された製品４に関する仕様データの一例を示す。なお、製品４に関する仕様データは、仕様データ登録処理によって登録された仕様データであり、再利用した仕様データはないものとする。

図１１に示すように、本実施形態における製品１に関する仕様データ２５ａＤは、階層構造のデータであり、「上位機能ＩＤ」欄に格納されたＩＤが上位階層にある仕様データを示す。

続いて、図１２を参照して、製品４を再利用して作成された製品５に関する仕様データについて説明する。図１２に示すように、製品５の仕様データ２５ａＥにおいて製品４から変更した機能は、外部記憶媒体の追加である。また、製品５において製品４の仕様データを再利用した仕様データは、仕様ＩＤ：２０１１、２０１２、２０１３、２０１４、２０２１、２０２２、２０２３の機能である。

図１３を参照して、製品５を再利用して作成された製品６に関する仕様データについて説明する。図１３に示すように、製品６の仕様データ２５ａＦにおいて製品５から変更した機能は、ＷｉＦｉ（登録商標）機能の追加である。また、製品６において製品５の仕様データを再利用した仕様データは、仕様ＩＤ：３０１１、３０１２、３０１３、３０１４、３０２１、３０２２、３０２３、３０３１、３０３２の機能である。

図１４乃至図１７を参照して、本実施形態のソフトウェア資産再利用支援装置１０におけるフィーチャーモデル候補構築処理の一例について説明する。

まず、ユーザがユーザインターフェース部２１を介して、フィーチャーモデル候補構築対象の製品系列名を含むフィーチャーモデル候補構築要求を入力する（ステップＳ５１）。制御部２２は入力されたフィーチャーモデル候補構築要求をフィーチャーモデル候補構築部２８に送信する（ステップＳ５２）。

フィーチャーモデル候補構築部２８は、フィーチャーモデル候補構築対象の製品系列名に基づいて、この製品系列に属する製品ごとに最上位の仕様データを仕様データＤＢ２５から取得する（ステップＳ５３）。ここでは、図１１に示した製品４の仕様データ２５ａＤにおける、機能ＩＤがＦ０１とＦ０２との仕様データが取得される。また、図１２に示した製品５の仕様データ２５ａＥにおける、機能ＩＤがＦ０１とＦ０２とＦ０３の仕様データが取得される。また、図１３に示した製品６の仕様データ２５ａＦにおける、機能ＩＤがＦ０１とＦ０２とＦ０３の仕様データが取得される。

続いて、フィーチャーモデル候補構築部２８の仕様データ関連性分析部２９は、フィーチャーモデル候補構築部２８がステップＳ５３で取得した最上位の仕様データについて、図７のステップＳ３４〜ステップＳ４０の処理を行う（ステップＳ５４）。

図１５に、ステップＳ５４で作成されるフィーチャーモデル候補の一例を示す。ここでは、第１階層の仕様データに関するフィーチャーモデル候補が作成される。図１５に示すように、本実施形態の第１階層の仕様データは、「通話機能」、「機器通信機能」、「外部記憶媒体」である。このうち「外部記憶媒体」は、製品４、５でのみ実現するフィーチャーである。従って「外部記憶媒体」は「選択」と判定される。

ステップＳ５４の処理が終了すると、フィーチャーモデル候補構築部２８は、ステップＳ５１で取得した最上位の仕様データのうち、下位の仕様データを持つ仕様データ（以下、起点フィーチャーという）を１つ選択する（ステップＳ５５）。フィーチャーモデル候補構築部２８による下位の仕様データを持つ仕様データの判定は、具体的にはステップＳ５１で取得した、最上位の仕様データが有する機能ＩＤが、最上位以外の仕様データに含まれる上位機能ＩＤ欄に格納されているかを確認することによって行なう。

仕様データ関連性分析部２９は、フィーチャーモデル候補構築部２８によって選択された起点フィーチャーの下位に属する仕様データを製品毎に抽出する（ステップＳ５６）。

仕様データ関連性分析部２９は、ステップＳ５６で抽出した仕様データについて、図７のステップＳ３４〜ステップＳ４０の処理を行い、フィーチャーモデル候補を構築する（ステップＳ５７）。

フィーチャーモデル候補構築部２８の仕様データ関連性分析部２９は、ステップＳ５７で構築したフィーチャーモデル候補を、起点フィーチャーの配下に設置する（ステップＳ５８）。

ここで、仕様データ関連性分析部２９は、ステップＳ５４で取得した下位の仕様データをフィーチャーモデルに取り込んでいない仕様データがあるかを判定する（ステップＳ５９）。

ステップＳ５４で取得した仕様データに、下位の仕様データをフィーチャーモデルに取り込んでいない仕様データがある場合（ステップＳ５９がＹｅｓ）、仕様データ関連性分析部２９は、この下位の仕様データをフィーチャーモデルに取り込んでいない仕様データを選択する（ステップＳ６０）。その後、仕様データ関連性分析部２９はステップＳ５６に進み、処理を繰り返す。

図１６に、本実施形態においてステップＳ５６〜ステップＳ６０の処理の繰り返しによって作成されるフィーチャーモデル候補の一例を示す。図１６には、図１５に示した第１階層のフィーチャーモデルの下位フィーチャーが配置されている。図１６に示すように、「通話機能」の下位フィーチャーである「発信」、「着信」、「留守電」フィーチャーは全て必須フィーチャーである。また、「機器通信機能」の下位フィーチャーは、「赤外線通信機能」、「Ｂｌｕｅｔｏｏｔｈ（登録商標）通信機能」、「ＷｉＦｉ（登録商標）機能」の３つである。「赤外線通信機能」、「Ｂｌｕｅｔｏｏｔｈ（登録商標）通信機能」は必須フィーチャーであり、「ＷｉＦｉ（登録商標）機能」は、製品６のみが利用する機能であるため、選択フィーチャーである。同様に、「外部記憶媒体」の下位フィーチャーは、「ＳＤカードアクセス機能」である。なお、「ＳＤカードアクセス機能」のように選択フィーチャーの下位フィーチャーの場合、上位のフィーチャーを持つ製品だけを対照とし、関係性を判断する。本実施形態において「ＳＤカードアクセス機能」は対象製品である製品５と製品６の両方で利用しているので、必須フィーチャーである。

ステップＳ５４で取得した仕様データに、下位の仕様データをフィーチャーモデルに取り込んでいない仕様データがない場合（ステップＳ５９がＮｏ）、仕様データ関連性分析部２９は、ステップＳ５６で取得した下位の仕様データを、フィーチャーモデルに取り込んでいない仕様データがあるかを判定する（ステップＳ６１）。

ステップＳ５６で取得した下位の仕様データを、フィーチャーモデルに取り込んでいない仕様データがある場合（ステップＳ６１がＹｅｓ）、ステップＳ６０に進む。

ステップＳ５６で取得した下位の仕様データを、フィーチャーモデルに取り込んでいない仕様データがない場合（ステップＳ６１がＮｏ）、仕様データ関連性分析部２９は、フィーチャーモデル候補構築処理は終了する。

図１７に、本実施形態におけるフィーチャーモデル候補構築処理によって構築されたフィーチャーモデル候補の一例を示す。図１７に示すように、本実施形態では第３階層までのフィーチャーモデルが作成される。

上述のように、本実施形態のソフトウェア資産再利用支援装置１０によると、階層型の仕様データからフィーチャーモデルの候補を生成することが可能である。

以上、本発明のいくつかの実施形態を説明したが、これら実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０…ソフトウェア資産再利用支援装置、１１…記憶装置、１２…キーボード、１３…マウス、１４…中央演算装置、１５…ディスプレイ、２１…ユーザインターフェース部、２２…制御部、２３…仕様データ登録部、２４…仕様データＩＤ付与部、２５…仕様データデータベース、２６…仕様データ取得部、２７…再利用ＩＤ設定部、２８…フィーチャーモデル候補構築部、２９…仕様データ関連性分析部、３０…パターンデータベース

Claims (4)

1. 製品系列と当該製品系列に属する製品毎の仕様とを定義する仕様データが入力されるユーザインターフェース部と、
   製品系列と前記仕様データと当該仕様データの識別子である仕様ＩＤとを関連付けて記憶する仕様データ記憶部と、
   前記ユーザインターフェース部に入力された仕様データに基づいて、前記仕様データ記憶部から、前記仕様ＩＤに関連付けられている前記仕様データを取得する仕様データ取得部と、
   前記仕様データ取得部によって取得された仕様データと前記ユーザインターフェース部によって入力された仕様データとが合致するか否かを検索し、合致する場合に前記仕様データ取得部によって取得された仕様データの仕様ＩＤを前記ユーザインターフェース部によって入力された仕様データの再利用ＩＤとして設定する再利用ＩＤ設定部と、
   前記仕様データ記憶部に記憶された前記仕様データと前記製品系列に属する製品群との関連性を分析するルールを定めるパターン情報を記憶するパターン記憶部と、
   前記仕様データ記憶部に記憶された前記仕様データと当該仕様データの前記仕様ＩＤと前記再利用ＩＤ、および、パターン記憶部に記憶された前記パターン情報を用いて、前記パターン情報について、前記仕様データ記憶部に記憶された前記仕様データが、前記製品系列に属する全製品の仕様データに共通に含まれるか否かを示す条件、および、前記仕様データ記憶部に記憶された前記仕様データが、前記製品系列に属する全製品の仕様データに共通に含まれない場合、当該仕様データが属する製品系列の他の仕様データに、前記仕様データと排他的な仕様データがあるか否かを示す条件、に着目し、前記製品系列における前記仕様データの関連性を判定する関連性判定部と、
   前記関連性判定部による判定結果に基づいてフィーチャーモデル候補を構築するフィーチャーモデル候補構築部と、
   を備えるソフトウェア資産再利用支援装置。
2. 前記ユーザインターフェース部は、前記フィーチャーモデル候補構築部によって構築されたフィーチャーモデル候補を表示する請求項１に記載のソフトウェア資産再利用支援装置。
3. 前記ユーザインターフェース部によって入力された仕様データと関連付けて前記再利用ＩＤが前記仕様データ記憶部に登録される登録部を備える請求項１または請求項２に記載のソフトウェア資産再利用支援装置。
4. 製品系列と当該製品系列に属する製品毎の仕様とを定義する仕様データと、当該仕様データの識別子である仕様ＩＤとを関連付けて記憶する仕様データ記憶部を備えるソフトウェア資産再利用支援装置のソフトウェア資産再利用支援プログラムであって、
   前記ソフトウェア資産再利用支援装置のコンピュータに、
   入力された前記製品系列と当該製品系列に属する製品毎の仕様とを定義する仕様データに基づいて、前記仕様データ記憶部から前記仕様ＩＤに関連付けられている前記仕様データを取得する機能と、
   取得された仕様データと前記ユーザインターフェース部によって入力された仕様データとが合致するか否かを検索し、合致する場合に前記仕様データ取得部によって取得された仕様データの仕様ＩＤを前記ユーザインターフェース部によって入力された仕様データの再利用ＩＤとして設定する機能と、
   前記仕様データ記憶部に記憶された前記仕様データと前記製品系列に属する製品群との関連性を分析するルールを定めるパターン情報を記憶する機能と、
   前記仕様データ記憶部に記憶された前記仕様データと当該仕様データの前記仕様ＩＤと前記再利用ＩＤ、および、パターン記憶部に記憶された前記パターン情報とを用いて、前記仕様データについて、前記仕様データ記憶部に記憶された前記仕様データが、前記製品系列に属する全製品の仕様データに共通に含まれるか否かを示す条件、および、前記仕様データ記憶部に記憶された前記仕様データが、前記製品系列に属する全製品の仕様データに共通に含まれない場合、当該仕様データが属する製品系列の他の仕様データに、前記仕様データと排他的な仕様データがあるか否かを示す条件、に着目し、前記製品系列における前記仕様データの関連性を判定する機能と、
   前記仕様データの関連性を判定する機能による判定結果に基づいてフィーチャーモデル候補を構築する機能と、
   を実現させるソフトウェア資産再利用支援プログラム。

Images