JP2008077449A - ソフトウェア開発支援システムおよび支援方法 - Google Patents

Abstract

【課題】ソフトウェアの開発工数の見積もりを容易にし、さらに開発工数も削減する。
【解決手段】ＵＭＬ図のユースケース図よりユースケースを抽出し、そのユースケースに関連付けられているアクティビティ図を抽出し、アクティビティ図からデータファンクションを計測し、アクティビティ図のアクション状態からトランザクションファンクションポイントとして計測する。データファンクションとトランザクションファンクションを加えた値に、一般システム特性への影響度から求めた調整係数を掛け合わせてファンクションポイントを求め、単位ファンクションポイント当たりの開発工数をファンクションポイントに掛け合わせてソフトウェアの開発工数を求める。ユースケース図、クラス図、アクティビティ図からＣＯＳＭＩＣ−ＦＦＰ法によって開発工数を見積もることも含む。
【選択図】図１

Description

本発明は、ソフトウェア開発支援システムおよび支援方法に係り、特に要求仕様を統一モデリング言語で表記したソフトウェアの開発工数の見積もりを支援するシステムおよび方法に関する。

統一モデリング言語（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ、以下ＵＭＬ）は、ソフトウェア開発のためのモデリング言語であり、ソフトウェア開発対象システムの構造を表現するための表記法で、開発者同土の意思疎通を容易にする。

一方、ソフトウェア機能量測定法の一つにファンクションポイント法があり、この方法はソフトウェアプロジェクトの規模測定法で、基本的には論理設計に基づき、ユーザに提供する機能を定量化することによりソフトウェアの規模を計測するものである。

ＵＭＬで表現された要求仕様に対してファンクションポイント法を適用するための計測値を算出し、ソフトウェア開発工数の自動見積もりを可能にした手法を、本願出願人は既に提案している（例えば、特許文献１参照）。

また、ソフトウェア機能量測定法の一つにＣＯＳＭＩＣ−ＦＦＰ（Ｆｕｌｌ Ｆｕｎｃｔｉｏｎ Ｐｏｉｎｔ）測定法がある。この測定法の概要を図１９に示す。測定対象ソフトウェアの機能は、データの移動を伴う機能プロセスの中のサブプロセス（データ移動サブプロセス）であり、データの操作を行う機能プロセスの中のサブプロセス（データ操作サブプロセス）ではない。ここで、データの移動とは、ユーザや他のサブシステムから機能に入るエントリ（Ｅ）、機能からユーザや他のサブシステムに出て行くイグジット（Ｘ）、記憶領域から読み込むリード（Ｒ）、記憶領域に書き込むライト（Ｗ）の４つで構成され、データ移動サブプロセスと呼ぶ。これらのデータ移動サブプロセスを計数して機能量を算出し、ソフトウェアの見積もりに利用する。
特開２００５−２１２１８３号公報

ソフトウェア開発におけるファンクションポイント法によるソフトウェア開発工数の見積もりは、仕様書からユーザに提供される機能を洗い出すことから始める。一方、ソフトウェア開発における分析・設計は、同様に仕様書からユーザに提供される機能を洗い出す作業を別途行なう。どちらも同じ作業を行なうため、工数の無駄が発生する。また、ソフトウェア開発の途中で仕様変更が生じると、両方の見直しを行なう必要がある。

前記の特許文献１の手法では、ＵＭＬのユースケース図、クラス図およびコラボレーション図を作成することにより、ファンクションポイント法による見積もりを自動化している。ユースケース図からファンクションポイント法におけるトランザクションファンクションの外部入力（ＥＩ）と外部出力（ＥＯ）および外部照会（ＥＱ）を計測する。そのため、アクタとユースケース間の関係の線に、上記三者のタイプをラベル付けする。すなわち、ファンクションポイント法の内容を理解している必要があり、ＵＭＬにそれ専用のデータを適切に付加する必要がある。

別の見積もり手法であるＣＯＳＭＩＣ−ＦＦＰ測定法は多くの手間を必要とする問題がある。すなわち、ＣＯＳＭＩＣ−ＦＦＰ法の場合、機能やその機能のトリガとなるイベントを抽出し、データ移動サブプロセスを計測することによって、機能量を算出し、見積もりを行うが、その際に、表形式の資料を人手で作成する必要がある。

本発明の目的は、ソフトウェアの開発工数の見積もりを容易にし、さらにソフトウェアの開発工数の削減もできるソフトウェア開発支援システムおよび支援方法を提供することにある。

前記の課題を解決するため、本発明は、以下のシステムおよび方法を特徴とする。

（システムの発明）
（１）要求仕様をＵＭＬで表記したソフトウェアの開発工数を、ファンクションポイント法により見積もるソフトウェア開発支援システムであって、
要求仕様書から作成されたＵＭＬ図のユースケース図、クラス図、アクティビティ図をデータとして取得する手段と、
前記ユースケース図より、測定対象のアクタとユースケース間の関係の線に接続しているユースケースを抽出し、そのユースケースに関連付けられているアクティビティ図を抽出する手段と、
抽出された前記アクティビティ図のスイムレーンのうち、システム内部に所属するオブジェクトを内部論理ファイル（ＩＬＦ）とし、システム外部に所属するオブジェクトを外部インタフェースファイル（ＥＩＦ）とし、これらファイル（ＩＬＦ、ＥＩＦ）上のユニークで繰り返しを含まないフィールド個数（ＤＥＴ）およびこれらファイルに含まれるフィールド個数（ＲＥＴ）を計測し、両フィールド個数の複雑さをデータファンクションとして計測する手段と、
抽出された前記アクティビティ図のアクション状態およびオブジェクトフローから、すべてのアクション状態について測定対象への外部入力（ＥＩ）と外部出力（ＥＯ）および外部照会（ＥＱ）を計測し、各アクション状態に関係する前記両フィールド個数から求める外部入力（ＥＩ）と外部出力（ＥＯ）および外部照会（ＥＱ）の複雑さをトランザクションファンクションポイントとして計測する手段と、
前記データファンクションとトランザクションファンクションを加えた値に、一般システム特性（ＧＳＣ）の各項目について予め設定された影響度（ＤＩ）から求めた調整係数（ＶＡＦ）を掛け合わせてファンクションポイントを求める手段と、
単位ファンクションポイント当たりの開発工数を前記ファンクションポイントに掛け合わせてソフトウェアの開発工数を求める手段を備えたことを特徴とする。

（２）要求仕様をＵＭＬで表記したソフトウェアの開発工数を、ＣＯＳＭＩＣ−ＦＦＰ法によって見積もるソフトウェア開発支援システムであって、
要求仕様書から作成されたＵＭＬ図のユースケース図、クラス図、アクティビティ図をデータとして取得する手段と、
ＣＯＳＭＩＣ−ＦＦＰ法におけるユーザを前記ユースケース図のアクタとし、機能をユースケースとし、機能のイベントトリガをアクタとユースケース間の関係の線として付加したアクティビティ図を抽出する手段と、
抽出された前記アクティビティ図のスイムレーンのうち、システム外部にあるデータグループからシステム内部のサブプロセスへのデータ移動をエントリ（Ｅ）とし、システム内部のサブプロセスからシステム内部にあるデータグループへのデータ移動をライト（Ｗ）とし、システム内部にあるデータグループからシステム内部のサブプロセスへのデータ移動をリード（Ｒ）とし、システム内部にあるサブプロセスからシステム外部にあるデータグループへのデータ移動をイグジット（Ｅ）とし、これらデータ移動サブプロセスを計数して機能量を算出してソフトウェアの開発工数を求める手段を備えたことを特徴とする。

（３）前記ユースケース図、クラス図、アクティビティ図から求めたアクタやユースケースなどの各エンティティに対して、開発プロジェクト単位に共通のＩＤをつけて管理する手段と、
前回の開発プロジェクトの開発工数の見積もり時に作成した各エンティティのうち、前記ＩＤを元にして当該プロジェクトの機能改良に対応するエンティティのみを計測対象として、機能改良に要する差分の開発工数を算出する手段を備えたことを特徴とする。

（方法の発明）
（４）要求仕様をＵＭＬで表記したソフトウェアの開発工数を、ファンクションポイント法により見積もるソフトウェア開発支援方法であって、
要求仕様書から作成されたＵＭＬ図のユースケース図、クラス図、アクティビティ図をデータとして取得する過程と、
前記ユースケース図より、測定対象のアクタとユースケース間の関係の線に接続しているユースケースを抽出し、そのユースケースに関連付けられているアクティビティ図を抽出する過程と、
抽出された前記アクティビティ図のスイムレーンのうち、システム内部に所属するオブジェクトを内部論理ファイル（ＩＬＦ）とし、システム外部に所属するオブジェクトを外部インタフェースファイル（ＥＩＦ）とし、これらファイル（ＩＬＦ、ＥＩＦ）上のユニークで繰り返しを含まないフィールド個数（ＤＥＴ）およびこれらファイルに含まれるフィールド個数（ＲＥＴ）を計測し、両フィールド個数の複雑さをデータファンクションとして計測する過程と、
抽出された前記アクティビティ図のアクション状態およびオブジェクトフローから、すべてのアクション状態について測定対象への外部入力（ＥＩ）と外部出力（ＥＯ）および外部照会（ＥＱ）を計測し、各アクション状態に関係する前記両フィールド個数から求める外部入力（ＥＩ）と外部出力（ＥＯ）および外部照会（ＥＱ）の複雑さをトランザクションファンクションポイントとして計測する過程と、
前記データファンクションとトランザクションファンクションを加えた値に、一般システム特性（ＧＳＣ）の各項目について予め設定された影響度（ＤＩ）から求めた調整係数（ＶＡＦ）を掛け合わせてファンクションポイントを求める過程と、
単位ファンクションポイント当たりの開発工数を前記ファンクションポイントに掛け合わせてソフトウェアの開発工数を求める過程を備えたことを特徴とする。

（５）要求仕様をＵＭＬで表記したソフトウェアの開発工数を、ＣＯＳＭＩＣ−ＦＦＰ法によって見積もるソフトウェア開発支援方法であって、
要求仕様書から作成されたＵＭＬ図のユースケース図、クラス図、アクティビティ図をデータとして取得する過程と、
ＣＯＳＭＩＣ−ＦＦＰ法におけるユーザを前記ユースケース図のアクタとし、機能をユースケースとし、機能のイベントトリガをアクタとユースケース間の関係の線として付加したアクティビティ図を抽出する過程と、
抽出された前記アクティビティ図のスイムレーンのうち、システム外部にあるデータグループからシステム内部のサブプロセスへのデータ移動をエントリ（Ｅ）とし、システム内部のサブプロセスからシステム内部にあるデータグループへのデータ移動をライト（Ｗ）とし、システム内部にあるデータグループからシステム内部のサブプロセスへのデータ移動をリード（Ｒ）とし、システム内部にあるサブプロセスからシステム外部にあるデータグループへのデータ移動をイグジット（Ｅ）とし、これらデータ移動サブプロセスを計数して機能量を算出してソフトウェアの開発工数を求める過程を備えたことを特徴とする。

（６）前記ユースケース図、クラス図、アクティビティ図から求めたアクタやユースケースなどの各エンティティに対して、開発プロジェクト単位に共通のＩＤをつけて管理する過程と、
前回の開発プロジェクトの開発工数の見積もり時に作成した各エンティティのうち、前記ＩＤを元にして当該プロジェクトの機能改良に対応するエンティティのみを計測対象として、機能改良に要する差分の開発工数を算出する過程を備えたことを特徴とする。

以上のとおり、本発明によれば、ソフトウェアの開発工数の見積もりを容易にし、さらにソフトウェアの開発工数の削減もできる。具体的には、
（１）ＵＭＬのユースケース図、クラス図、アクティビティ図を作成することにより、ファンクションポイント法の内容を知らなくても、簡単にファンクションポイント法によるソフトウェア開発の見積もりを行うことができる。

（２）ＵＭＬのユースケース図、クラス図、アクティビティ図を作成することにより、簡単にＣＯＳＭＩＣ−ＦＦＰ法によるソフトウェア開発の見積もりを行うことができる。

（３）ソフトウェア開発の見積もりのために作成したＵＭＬの各図を、ソフトウェア開発の分析・設計時にも利用することができるため、ソフトウェア開発全体の工数削減を図ることができる。

（４）プロジェクトごとのＩＤ管理を行うことにより、機能の追加や削除などの仕様変更に対しても、ファンクションポイント法やＣＯＳＭＩＣ−ＦＦＰ法によるソフトウェア開発の差分の見積もりを、簡単に行うことができる。

（５）ファンクションポイント法の一般システム特性の影響度を、ＸＭＬ形式のファイルに保存することにより、次回同じ設定をこのファイルを読み込むだけで行うことができる。

（実施形態１）
本実施形態は、新規開発プロジェクトにおいて、ＵＭＬで表現された要求仕様に対してファンクションポイント法による計測を基にしてソフトウェアの開発工数を見積もり、さらにソフトウェアを分析、設計する場合であり、全体の見積もり処理の流れを図１に示し、このうちの見積もり処理を実行するコンピュータ処理手順を図２に示す。以下、各手順の詳細を説明する。

（１．１）ＵＭＬ図の作成
（１）仕様書よりＵＭＬ図のユースケース図、クラス図、アクティビティ図を作成する。これらは図１に示すように、プロジェクトの開発者によって作成され、これらはデータとして開発支援システムのコンピュータに取得可能にされる。

ユースケース図では、図３に示すように、開発対象のシステムに、どのようなユーザが存在するかをアクタとして表現する。また、各ユーザに提供する機能をユースケースとして表現する。あるユーザに提供する機能であることを表現するために、アクタとユースケース間に関係の線を結ぶ。このとき、測定の対象とするかどうかの情報を、この関係の線に付加する。

クラス図では、図４に示すように、開発対象のシステムに、どのようなデータが存在するかをクラスとして表現する。

アクティビティ図では、図５に示すように、上記のユースケース図で作成した各ユースケースに対して、大まかな処理の流れを表現する。図中に示すスイムレーンを利用してシステム内部とシステム外部を区別し、上記のクラス図で作成したクラスをデータとして（オブジェクトという）、アクティビティ図のアクション状態を処理の単位として、表現する。このとき、アクティビティ図がどのユースケースのものであるかを特定できるように、ユースケースにアクティビティ図を関連付けておく。

（２）見積もり処理（図２）。

ユースケース図より、測定対象のアクタとユースケース間の関係の線を抽出する。その関係の線に接続しているユースケースを抽出する。そのユースケースに関連付けられているアクティビティ図を抽出する。

（ａ）データファンクションの計測
アクティビティ図を利用する。アクティビティ図（図５参照）のスイムレーンのうち、システム内部に所属するオブジェクトを、内部論理ファイル（システム内部で維持管理されるデータ、以下ＩＬＦ）として計測する。また、システム外部に所属するオブジェクトを、外部インタフェースファイル（システム外部で維持管理されるデータ、以下ＥＩＦ）として計測する。

実際の見積もりに必要なデータ、データ項目（ＩＬＦやＥＩＦ上のユニークで繰り返しを含まないデータ項目、以下ＤＥＴ）と、レコード種別（ＩＬＦやＥＩＦに含まれるデータ項目を構成する下位のデータ、以下ＲＥＴ）について、以下の通りに計測する。

・ＤＥＴは、上記で抽出したオブジェクトの元になるクラスのうち、自分自身のクラスのみのフィールドの個数を計測する。このとき、当該クラスがスーパークラスの汎化である場合、そのスーパークラスのフィールドの個数も計測対象とする。図６の例では、ＤＥＴは合計７つになる。

・ＲＥＴは、上記で抽出したオブジェクトの元になるクラスに、関連するクラスおよびサブクラスのフィールドの個数を計測する。ファンクションポイント法では、これらの値に０をとらないので、どちらもフィールドの個数が０の場合は、１として計測する。図７の例では、ＲＥＴは合計３つになる。

すべてのＩＬＦ，ＥＩＦについて、ＤＥＴとＲＥＴを計測する。これらＤＥＴとＲＥＴの総計から、図８に示すように、複雑さを算出して、その合計をデータファンクション（未調整ファンクションポイント）として計測する。

（ｂ）トランザクションファンクションの計測
この計測には、アクティビティ図のアクション状態およびオブジェクトフローを利用する。実際の見積もりに必要なデータ、外部入力（計測するアプリケーションの境界の外部から入ってくるデータや制御情報を処理する要素処理、以下ＥＩ）、外部出力（計測するアプリケーションの境界の外部に出力するデータや制御情報を送り出す要素処理、以下ＥＯ）、外部照会（データおよび制御情報をアプリケーション境界の外に送り出す要素処理、以下ＥＱ）について、以下の通りに設定する。

・ＥＩは、スイムレーン（システム内部とシステム外部）をまたがるオブジェクトフローが１つ以上あり、それらが内部から外部、および、外部から内部の、両方存在する場合である。

・ＥＯは、スイムレーン（システム内部とシステム外部）をまたがるオブジェクトフローが１つ以上あり、それらがすべて内部から外部のみの場合である。

・ＥＱは、スイムレーン（システム内部とシステム外部）をまたがるオブジェクトフローが１つ以上あり、それらがすべて外部から内部のみの場合である。

図９にＥＱが１つになる場合を示すように、すべてのアクション状態について、ＥＩ，ＥＯ，ＥＱを計測する。各アクション状態に関係するオブジェクトから（ａ）のデータファンクションの計測を行う。図１０の例では、これらＥＩ，ＥＯ，ＥＱの複雑さからトランザクションファンクションポイントへ変換し、その合計とトランザクションファンクションポイント（未調整ファンクションポイント）として計測する。

（ｃ）調整係数の算定
図１１に示すように、一般システム特性（ＧＳＣ）１４項目について、影響度（ＤＩ）を入力する。ＵＭＬの図では表現することができないので、ウィザード（アンケート）形式のダイアログを作成し、それぞれ５つの選択肢から選択する、簡単な方法で設定できるようにする。なお、ＧＳＣは、データ通信、分散処理、性能など１４項目あるが、いずれもファンクションポイント法の内容とは無関係であるため、ファンクションポイント法の内容を知っている必要はない。

調整係数（以下ＶＡＦ）は、以下の式で求められる。
［数１］ＶＡＦ＝（ＧＳＣのＤＩの合計×０．０１）＋０．６５
以上（ａ）〜（ｃ）で計測した値を元に、ファンクションポイントを以下の通りに計測する。

［数２］ ファンクションポイント＝未調整ファンクションポイント×調整係数
＝（データファンクション＋トランザクションファンクション）×調整係数
図５の場合、調整係数が図１１の調整係数１．０７を使って、ファンクションポイント＝（１７＋７）×１．０７＝２５．６８となる。

設定した一般システム特性の影響度ＤＩをＸＭＬ形式にファイル保存しておけば、次回そのファイルを指定することで同じ影響度を容易に設定できる。

（１．２）開発工数の見積もり
単位ファンクションポイント（１ファンクションポイント）当たりの開発工数を、過去の実績から設定する。開発工数は、その値に上記で計測したファンクションポイントを掛け合わせることで、求めることができる。

［数３］ 開発工数＝単位ファンクションポイント×ファンクションポイント
（１．３）ソフトウェア開発の分析・設計
上記の見積もりのために、仕様書から作成したＵＭＬのユースケース図やクラス図、アクティビティ図を元に、それらの図を詳細化していくことで、開発対象ソフトウェアの分析・設計を行う。

（ａ）ユースケース図
見積もりのための大まかなユースケース図を詳細化していく。以下に例を挙げる。

・複数のユースケースに共通の機能が存在する場合、それを１つのユースケースとして作成し、＜ｉｎｃｌｕｄｅ＞関係として関連付ける（包含）。

・あるユースケースのオプション的な機能が存在する場合、それを１つのユースケースとして作成し、＜ｅｘｔｅｎｄ＞関係として関連付ける（拡張）。

（ｂ）クラス図
見積もりのための大まかなクラス図を詳細化していく。以下に例を挙げる。

・データだけのクラスに対して、処理を表すメソッドを追加する。

・それらのクラスを扱うためのクラスを追加する。

・機能を実現するためのクラスを追加する。

（実施形態２）
本実施形態は、機能改良プロジェクトにおけるファンクションポイントの計測を簡易にするものである。

実施形態１で作成したＵＭＬの各エンティティ（アクタやユースケースなど）に対して、開発プロジェクト単位に共通のＩＤをつけて管理しておく。このＩＤを元にして、機能改良プロジェクト（前プロジェクトとは異なるＩＤ）において作成したＵＭＬの各エンティティのみを計測対象として、実施形態１と同様の手法で各ファンクションポイントを算出し、必要ならば調整係数を設定しなおして、機能改良に要する差分の開発工数を算出する。ＩＤを問わなければ、全体の開発工数を算出することができる。

また、ＵＭＬの各図は、以前のプロジェクトと同じ図を使用し、引き続き機能改良の分析・設計を行うことができる。

（実施形態３）
本実施形態は、新規プロジェクトの開発において、ＣＯＳＭＩＣ−ＦＦＰ法を基にしてソフトウェアの開発工数を見積もる場合であり、全体の処理の流れを図１２に示し、コンピュータを利用した見積もり処理を図１３に示す。以下、各手順の詳細を説明する。

（３．１）機能の抽出
ＵＭＬのユースケース図を利用する。図１４に例を示すように、ＣＯＳＭＩＣ−ＦＦＰ法におけるユーザをユースケース図のアクタで表現し、機能をユースケースで表現する。機能のイベントトリガをアクタとユースケース間の関係の線に、付加情報として追加する。

（３．２）データ移動の抽出
ＵＭＬのアクティビティ図を利用する。上記で作成したユースケースごとにアクティビティ図を作成し、処理の流れを表記するとともに、図１５に示すように、ＣＯＳＭＩＣ−ＦＦＰ法のデータ移動サブプロセスを表記する。スイムレーンを利用して、システム内部とシステム外部を区別する。各データ移動は、以下の通りに設定する。

・システム外部にあるデータグループ（ＵＭＬでは、オブジェクト）から、システム内部のサブプロセス（ＵＭＬでは、アクション状態）へのデータ移動（ＵＭＬでは、オブジェクトフロー）を、エントリ（Ｅ）とする。

・システム内部のサブプロセス（ＵＭＬでは、アクション状態）から、システム内部にあるデータグループ（ＵＭＬでは、オブジェクト）へのデータ移動（ＵＭＬでは、オブジェクトフロー）を、ライト（Ｗ）とする。

・システム内部にあるデータグループ（ＵＭＬでは、オブジェクト）から、システム内部のサブプロセス（ＵＭＬでは、アクション状態）へのデータ移動（ＵＭＬでは、オブジェクトフロー）を、リード（Ｒ）とする
・システム内部にあるサブプロセス（ＵＭＬでは、アクション状態）から、システム外部にあるデータグループ（ＵＭＬでは、オブジェクト）へのデータ移動（ＵＭＬでは、オブジェクトフロー）を、イグジット（Ｅ）とする。

（３．３）機能量の算出
上記で作成したデータ移動サブプロセスを計測し、機能量を算出する。結果は、図１６に示すように、表形式の資料に自動的に作成する。

（３．４）ソフトウェア開発の分析・設計
実施形態１と同様に、上記の見積もりのために仕様から作成したＵＭＬのユースケース図やクラス図、アクティビティ図を元に、それらの図を詳細化していくことで、対象ソフトウェアの分析・設計を行う。

（実施形態４）
本実施形態は、機能改良プロジェクトにおけるＣＯＳＭＩＣ−ＦＦＰ法を基にしてソフトウェアの開発工数を見積もる場合である。

本実施形態では、実施形態２と同様に、実施形態３で作成したユースケース図やアクティビティ図をそのまま利用し、機能の追加や削除を行う。また、それに伴ってアクティビティ図を変更する。実施形態３で作成した図との区別をつけるために、図１７に示すように、プロジェクトごとに異なるＩＤを付けて管理する。また、機能改良プロジェクトで作成したＵＭＬの各エンティティに対してのみ計測対象として機能量を算出し、図１８に示すように、差分の工数を算出する。

ＩＤを問わなければ、全体の工数を算出することができる。ＵＭＬの各図は、以前のプロジェクトと同じ図を使用し、機能改良の分析・設計を行う。

本発明の実施形態１を示すファンクションポイント法による見積もり手順。 本発明の実施形態１を示すファンクションポイント法による見積もり処理。 ＵＭＬのユースケース図。 ＵＭＬのクラス図。 ＵＭＬのアクティビティ図。 データファンクションの計測（会員情報データのＤＥＴ）。 データファンクションの計測（会員情報データのＲＥＴ）。 データファンクションの計測（未調整ファンクションポイント）。 トランザクションファンクションの計測（個人情報を読み込む）。 トランザクションファンクションの計測（未調整ファンクションポイント）。 調整係数の設定例（データ通信の場合）。 本発明の実施形態３を示すＣＯＳＭＩＣ−ＦＦＰ法による見積もり手順。 本発明の実施形態３を示すＣＯＳＭＩＣ−ＦＦＰ法による見積もり処理。 ユースケース図による機能の表記。 アクティビティ図によるデータ移動の表記。 機能量の算出結果。 ＩＤによるソフトウェア仕様のバージョン管理。 機能量の差分算出結果。 ＣＯＳＭＩＣ−ＦＦＰ測定法。

Claims (6)

1. 要求仕様をＵＭＬで表記したソフトウェアの開発工数を、ファンクションポイント法により見積もるソフトウェア開発支援システムであって、
   要求仕様書から作成されたＵＭＬ図のユースケース図、クラス図、アクティビティ図をデータとして取得する手段と、
   前記ユースケース図より、測定対象のアクタとユースケース間の関係の線に接続しているユースケースを抽出し、そのユースケースに関連付けられているアクティビティ図を抽出する手段と、
   抽出された前記アクティビティ図のスイムレーンのうち、システム内部に所属するオブジェクトを内部論理ファイル（ＩＬＦ）とし、システム外部に所属するオブジェクトを外部インタフェースファイル（ＥＩＦ）とし、これらファイル（ＩＬＦ、ＥＩＦ）上のユニークで繰り返しを含まないフィールド個数（ＤＥＴ）およびこれらファイルに含まれるフィールド個数（ＲＥＴ）を計測し、両フィールド個数の複雑さをデータファンクションとして計測する手段と、
   抽出された前記アクティビティ図のアクション状態およびオブジェクトフローから、すべてのアクション状態について測定対象への外部入力（ＥＩ）と外部出力（ＥＯ）および外部照会（ＥＱ）を計測し、各アクション状態に関係する前記両フィールド個数から求める外部入力（ＥＩ）と外部出力（ＥＯ）および外部照会（ＥＱ）の複雑さをトランザクションファンクションポイントとして計測する手段と、
   前記データファンクションとトランザクションファンクションを加えた値に、一般システム特性（ＧＳＣ）の各項目について予め設定された影響度（ＤＩ）から求めた調整係数（ＶＡＦ）を掛け合わせてファンクションポイントを求める手段と、
   単位ファンクションポイント当たりの開発工数を前記ファンクションポイントに掛け合わせてソフトウェアの開発工数を求める手段を備えたことを特徴とするソフトウェア開発支援システム。
2. 要求仕様をＵＭＬで表記したソフトウェアの開発工数を、ＣＯＳＭＩＣ−ＦＦＰ法によって見積もるソフトウェア開発支援システムであって、
   要求仕様書から作成されたＵＭＬ図のユースケース図、クラス図、アクティビティ図をデータとして取得する手段と、
   ＣＯＳＭＩＣ−ＦＦＰ法におけるユーザを前記ユースケース図のアクタとし、機能をユースケースとし、機能のイベントトリガをアクタとユースケース間の関係の線として付加したアクティビティ図を抽出する手段と、
   抽出された前記アクティビティ図のスイムレーンのうち、システム外部にあるデータグループからシステム内部のサブプロセスへのデータ移動をエントリ（Ｅ）とし、システム内部のサブプロセスからシステム内部にあるデータグループへのデータ移動をライト（Ｗ）とし、システム内部にあるデータグループからシステム内部のサブプロセスへのデータ移動をリード（Ｒ）とし、システム内部にあるサブプロセスからシステム外部にあるデータグループへのデータ移動をイグジット（Ｅ）とし、これらデータ移動サブプロセスを計数して機能量を算出してソフトウェアの開発工数を求める手段を備えたことを特徴とするソフトウェア開発支援システム。
3. 前記ユースケース図、クラス図、アクティビティ図から求めたアクタやユースケースなどの各エンティティに対して、開発プロジェクト単位に共通のＩＤをつけて管理する手段と、
   前回の開発プロジェクトの開発工数の見積もり時に作成した各エンティティのうち、前記ＩＤを元にして当該プロジェクトの機能改良に対応するエンティティのみを計測対象として、機能改良に要する差分の開発工数を算出する手段を備えたことを特徴とする請求項１または２に記載のソフトウェア開発支援システム。
4. 要求仕様をＵＭＬで表記したソフトウェアの開発工数を、ファンクションポイント法により見積もるソフトウェア開発支援方法であって、
   要求仕様書から作成されたＵＭＬ図のユースケース図、クラス図、アクティビティ図をデータとして取得する過程と、
   前記ユースケース図より、測定対象のアクタとユースケース間の関係の線に接続しているユースケースを抽出し、そのユースケースに関連付けられているアクティビティ図を抽出する過程と、
   抽出された前記アクティビティ図のスイムレーンのうち、システム内部に所属するオブジェクトを内部論理ファイル（ＩＬＦ）とし、システム外部に所属するオブジェクトを外部インタフェースファイル（ＥＩＦ）とし、これらファイル（ＩＬＦ、ＥＩＦ）上のユニークで繰り返しを含まないフィールド個数（ＤＥＴ）およびこれらファイルに含まれるフィールド個数（ＲＥＴ）を計測し、両フィールド個数の複雑さをデータファンクションとして計測する過程と、
   抽出された前記アクティビティ図のアクション状態およびオブジェクトフローから、すべてのアクション状態について測定対象への外部入力（ＥＩ）と外部出力（ＥＯ）および外部照会（ＥＱ）を計測し、各アクション状態に関係する前記両フィールド個数から求める外部入力（ＥＩ）と外部出力（ＥＯ）および外部照会（ＥＱ）の複雑さをトランザクションファンクションポイントとして計測する過程と、
   前記データファンクションとトランザクションファンクションを加えた値に、一般システム特性（ＧＳＣ）の各項目について予め設定された影響度（ＤＩ）から求めた調整係数（ＶＡＦ）を掛け合わせてファンクションポイントを求める過程と、
   単位ファンクションポイント当たりの開発工数を前記ファンクションポイントに掛け合わせてソフトウェアの開発工数を求める過程を備えたことを特徴とするソフトウェア開発支援方法。
5. 要求仕様をＵＭＬで表記したソフトウェアの開発工数を、ＣＯＳＭＩＣ−ＦＦＰ法によって見積もるソフトウェア開発支援方法であって、
   要求仕様書から作成されたＵＭＬ図のユースケース図、クラス図、アクティビティ図をデータとして取得する過程と、
   ＣＯＳＭＩＣ−ＦＦＰ法におけるユーザを前記ユースケース図のアクタとし、機能をユースケースとし、機能のイベントトリガをアクタとユースケース間の関係の線として付加したアクティビティ図を抽出する過程と、
   抽出された前記アクティビティ図のスイムレーンのうち、システム外部にあるデータグループからシステム内部のサブプロセスへのデータ移動をエントリ（Ｅ）とし、システム内部のサブプロセスからシステム内部にあるデータグループへのデータ移動をライト（Ｗ）とし、システム内部にあるデータグループからシステム内部のサブプロセスへのデータ移動をリード（Ｒ）とし、システム内部にあるサブプロセスからシステム外部にあるデータグループへのデータ移動をイグジット（Ｅ）とし、これらデータ移動サブプロセスを計数して機能量を算出してソフトウェアの開発工数を求める過程を備えたことを特徴とするソフトウェア開発支援方法。
6. 前記ユースケース図、クラス図、アクティビティ図から求めたアクタやユースケースなどの各エンティティに対して、開発プロジェクト単位に共通のＩＤをつけて管理する過程と、
   前回の開発プロジェクトの開発工数の見積もり時に作成した各エンティティのうち、前記ＩＤを元にして当該プロジェクトの機能改良に対応するエンティティのみを計測対象として、機能改良に要する差分の開発工数を算出する過程を備えたことを特徴とする請求項４または５に記載のソフトウェア開発支援方法。