アイオス コーポレートブログ
ファンクションポイント法でデータファンクションを見つける
皆さん、こんにちは。技術開発グループのn-ozawanです。
今年は巳年になります。蛇は脱皮を繰り返して成長していくことから、変化や再生の象徴でもあります。一皮むけたい人は、この年、頑張ってみてはいかがでしょうか。
本題です。
ファンクションポイント法は、データとデータへの入出力からシステムの規模を測る手法です。今回はそんなデータの見つけ方についてお話しします。なお、本稿ではファンクションポイント法のデータファンクションに焦点を当てています。ファンクションポイント法の概要を知りたい方は以前の投稿を参照ください。
目次
データファンクション
データファンクションとは
データファンクションとは、アプリケーションが持つ論理的なファイルもしくはエンティティです。ファイルと言われるとHDDなどの記憶媒体に保存されるファイルをイメージするかと思います。しかし、「論理的な」とある通り、一貫性を持ったデータの集合体であり、記憶媒体に物理的に保存されるファイルと直接の関係がないことに注意が必要です。
本稿では前回の投稿で例示した以下の販売管理システムを例に、「販売管理」アプリケーションのデータファンクションを見つけてみたいと思います。
ILFとEIF
データファンクションはILFとEIFの２つに分類されます。
ILFとは、当該アプリケーションが維持管理しているファイルもしくはエンティティのデータの数、です。「維持管理」と言われるとなんだか難しく感じますが、要はそのデータを作成、更新、削除をするかどうか、です。CRUDのC(Create)、U(Update)、D(Delete)をしているかどうかですね。
EIFとは、当該アプリケーションが参照している、かつ、別のアプリケーションが維持管理しているファイルもしくはエンティティのデータの数、です。「別のアプリケーションが維持管理している」が大事で、どのアプリケーションも維持管理していない場合はEIFにはなりません。
販売管理の場合、売上情報とログに情報を書き込みますので、売上情報とログを維持管理していると言えます。なので、売上情報とログをILFとしてカウントします。一方で、マスタデータは参照のみを行いますので、EIFとしてカウントします。
住所を入力する際に、郵便番号から都道府県などの住所を自動的に反映する機能があったとします。その機能は、郵便局が公表している郵便番号と住所を紐づけたCSVファイルを参照して実現していることとします。この郵便番号住所CSVをEIFとカウントしたいところですが、この郵便番号住所CSVを維持管理している郵便局はアプリケーションではありませんので、EIFとしてカウントすることは出来ません。
このシステムでは、販売管理はバックオフィスからお知らせを受け取ります。受け取ったお知らせ内容は一般ユーザーが見えるように画面に表示します。その為、お知らせ内容は永続化した方が良いことが分かります。販売管理は、受け取ったお知らせ内容を保存し、一般ユーザーがアクセスしてきたら参照して画面に表示します。維持管理と参照の両方を行いますが、この場合はILFとしてカウントします。
DETとRET
DETは、ILFやEIF上のユーザーが識別可能なデータ項目の数です。例えば売上情報であれば、商品名称などの項目数がDETとなります。
RETはそのデータのサブグループ数です。例えば、商品を購入する際に、注文した人と発送先が同じ場合と、異なる場合があります。上図にある「発送先同一フラグ」がTRUEの場合、発送先名と発送先住所を空欄にするとします。その場合、注文者名と注文者住所は、注文者の情報と、発送先の情報の２つを持つ項目となります。RETはその数をカウントします。
複雑度とFP値
DETとRETから複雑度を求めます。
| DET | ||||
|---|---|---|---|---|
| 1～19 | 20～50 | 51以上 | ||
| RET | 1 | 単純 | 単純 | 普通 |
| 2～5 | 単純 | 普通 | 複雑 | |
| 6以上 | 普通 | 複雑 | 複雑 | |
求めた複雑度からFP値を求めます。
| 単純 | 普通 | 複雑 | |
|---|---|---|---|
| ILF | 7 | 10 | 15 |
| EIF | 5 | 7 | 10 |
気を付けるべき点
データファンクションでカウントする際に気を付けるべき点は以下になるかと思います。
DETとRETが極端に多くなってもFP値に影響しない
例えばDETが51でRETが1の場合、複雑度は普通になります。もし項目が極端に多く、DETが500になったとしても、複雑度は普通になります。同様にDETが10でRETが100であっても、複雑度は普通になります。結果として求められるFP値はいずれも10となります。
項目数が多くなればなるほどコーディング量が増えますので、工数の増大に繋がります。なのでFP値が増えないことに違和感を感じるかもしれません。しかし、FP値はそのシステムの規模を表す値であって、工数を表す値ではありません。DETが51でも500でもFP値が10なのはファンクションポイント法としては正しいのです。
このような事例の場合は、FP値から工数へ変換する際に考慮した方が良いでしょう。
DETとRETが微増減してもFP値が変わらない
例えば仕様変更などによりDETが10から12へ、2つ増えたとします。しかし2つ増えたところでFP値に変動はありません。もちろん、19から21、49から51などであればFP値が変わることがあるかもしれませんが、そのケースは限られています。
ちょっとした変更をファンクションポイント法で見積もるのは難しいかもしれません。
おわりに
実際にDETとRETをカウントしてみたのですが、ものすごい大変です。データファンクションの数が増えれば増えるほど、入力する数字も増えるので、見るのが億劫になります。また、どこか数え間違いしているのでは？と強迫観念に駆られて数えなおす・・・なんてこともありました。この辺をいい感じにカウントしてくれるツールが欲しいですね。
ではまた。
