JUDE APIでFPを算出するアプリ

JUDE5を使った上流工程(見積編)のまとめとして、JUDE5 ProのAPIを使ってファンクションポイントを算出するサンプルアプリを作ってみました。ソースコードは↓からダウンロードできるようにしておきます。

サンプルのeclipseプロジェクトをダウンロード

サンプルアプリケーションの仕様

JUDEでさくさくと書いた図からファンクションポイントが算出できたらとっても便利です。ということで、サンプルアプリでは、ユースケースとクラス(ERモデルから変換しても構いません)から以下の値を自動算出します。

  • モデルから自動的に算出できるもの
    • データファンクションのDET(クラスの属性の数*1
    • トランザクショナルファンクションのFTR(クラスが依存するユースケースの数 *2

もちろん、自動的に算出できない項目もあります。それらの値はJUDEからステレオタイプやタグ付き値として設定できる仕様としました。

  • モデルから算出できず、手動でJUDEに設定するもの
    • それを利用する機能から見てファイルの種類がILF(内部論理ファイル)であるかEIF(外部インターフェースファイル)であるか。*3


ユースケースからクラスへの依存線のステレオタイプとしてILF or EIFを設定。(青枠、緑枠部分)ファイルやテーブルへの書き込み処理の場合はILF、読み込み処理ならEIFを設定する。

    • データファンクションのRET(ファイルに含まれるサブグループの数 *4


↑ タグ付き値としてRETを設定(赤枠部分)

    • 各処理(ユースケースに相応)がEI/EO/EQいずれであるか。*5
    • トランザクショナルファンクションのDET(画面や帳票の項目数に相応)


↑ タグ付き値としてtype(EI or EO or EQ)とDETを設定(赤枠部分)。

アプリケーション境界の切り方

ファンクションポイント法で悩むのが、アプリケーション境界の切り方です。何故悩むかというと、切り方に厳密な決まりがないからで、一般的には「サブシステム単位」が良い、ということになっています。
私はどうしてるかというと、ユースケース(や画面・帳票)単位でアプリケーション境界を切ってしまっています。つまり、あるユースケースのファンクショナルファンクションポイントと、そのユースケースが利用するILFなりEIFファイル(テーブル)のファンクションポイントを全て足し上げてしまいます。
サブシステムの切り分け方には人によって違いがあり得ますが、ユースケースをアプリケーション境界と割り切ってしまえば、人によって違いが出ることはなく、何よりシンプルです。また、特に業務システムの場合、ロジックはテーブルに関する処理がほとんどであり、利用するテーブルが増えるほどファンクションポイントが増えるのは分かりやすいです。また、テーブルの数が増えるほどテスト量(=工数)が増えるのは現場感覚とマッチしてると思ってます。
例えば、先ほどの図を例にとるなら、注文ユースケースのFPは、「注文ユースケースのトランザクショナルFP + 注文テーブル(ILF)のデータFP + 注文明細(ILF)のデータFP + 商品マスタ(EIF)のデータFP」で計算し、商品を登録するユースケースのFPは、「商品を登録するトランザクショナルFP + 商品マスタ(ILF)のデータFP」で計算します。

実行結果

ちなみにサンプル(FPEstimatorクラス)を動かすと次のような結果が表示されます。

分析中 ... テスト用.jude

注文 [注文ID][注文日時][担当者] DET=3 RET=2 FP(ILF)=7 FP(total)=7
注文明細 [商品ID][注文ID] DET=2 RET=1 FP(ILF)=7 FP(total)=7
商品マスタ [商品ID][商品名][仕入れ価格][販売価格] DET=4 RET=1 FP(EIF)=5 FP(ILF)=7 FP(total)=12
** Data FP合計 = 26

注文する EI [商品マスタ][注文][注文明細] DET=100 FTR=3 FP=6
商品を登録する EI [商品マスタ] DET=30 FTR=1 FP=4
** Transactional FP合計 = 10

Data FPとTransactional FPの値を足し、調整係数を計算後、あなたのチームの生産性(単位期間あたりに消化できるFP)で割れば工数をはじき出せます。

JUDE APIを使ってみての感想など

今回は見積における一例を示しましたが、JUDEAPIにはいろいろと可能性を感じました。モデルや関連、依存、ステレオタイプなどの情報をAPIで扱えるので、ファンクションポイント以外の手法にも対応できそうな感じです。ちなみに、JUDEで開いているプロジェクトにはファイルロックがかかり、APIからは利用できなくなるので注意です。また、API自体のパフォーマンス(JUDEプロジェクトを読み込んだり、モデルを走査する)は、それほど機敏ではありませんが、主に分析用途に使う分には問題ないでしょう。

参考

調整係数の計算方法などファンクションポイントに関する正確な知識を得るには、一度きっちり本を読むことをお勧めします。私は「失敗のないファンクションポイント法」で勉強しました。

失敗のないファンクションポイント法

失敗のないファンクションポイント法

*1:テーブルの項目数にほぼ相応すると考えれば良いです。

*2:ユースケースから利用するテーブルの数に相応すると考えれば良いです。

*3:要はILFはCRUDのうちCUDいずれかの処理、EIFはRのみの処理です。

*4:例えば、社員マスタテーブルに、「パート区分」があったとして、パート区分に「1」が設定されている場合のみ、「時給」フィールドを設定する必要があったとします。この場合、パート区分が「0」、「1」いずれの場合も設定が必要なサブグループと、「1」の場合のみ設定が必要なサブグループの2種類となり、RETを2と計測します。

*5:EIは入力処理、EOは参照処理だと考えれば良いでしょう。EQは参照系のうち、ファイルから取得したデータの加工を行わず出力する特に単純な処理だと考えれば良いです。