ファンクションポイント（以下、FP）法について、なんとなく頭に残っていることをメモしておく。もう、ほっとんど忘れてしまったので、少し復習しながら。
「FP 法」については、聞いたことしかなかった*1し、もはや過去の手法だと思っていた。どんなイメージをもっていたかというと、要件定義 〜 外部設計で洗い出された「機能一覧」,「画面一覧」,「帳票一覧」,「外部 I/F 一覧」,「テーブル一覧」の行数を数えて、お終いだと。まぁせいぜい「組織ごとに機能の粒度をなるべく統一する」や「重みづけをして足し合わせる」くらいの工夫がある程度だと。
1 年前くらいに、ほんの少しだけ仕事でからんだのをきっかけに、もっと「きちんと」計測のルールがあることを知った。イメージとはかなり違っていて「データの項目数を細かく計測し、そこから規模を算出する方法」だった。確かに、いわゆる「機能一覧」にある機能なんて、粒度がてんでバラバラで、それの数を数えることに、ほとんど意味はないだろう。項目数をベースにすれば、ぶれは小さくなりそうだ。
そして、この時お世話になったのが、次の書籍。ただ、残念ながら、業務で計測できるレベルまでは到達しなかった。相も変わらず、自分の理解力のなさには辟易する。
実践!事例で学ぶファンクションポイント法―発注者も受注者もなっとく!ソフトウェアの規模が測れる手法
- 作者: 鵜澤仁
- 出版社/メーカー: 経済調査会
- 発売日: 2013/07/01
- メディア: 単行本
- この商品を含むブログを見る
もとい。この本では、今、最も普及している IFPUG 法が解説されている。そもそも、複数の方法があったことすら知らなかったのだが。
まずは、AP 境界（以下、境界）を設定するところからスタート。内外で分けてデータを数える、境界をまたぐデータを数える。ちなみに、データを数える際は、だいたい、次のように考える。
- ユーザが認識できないデータは、カウントしない。例えば、データベースの各テーブルにある、システム管理に用いるカラム（例えば、更新日時）など
- 実質的に「同じ」データは、カウントしない。例えば、入力したデータが、次画面で出力されている場合は、あわせて 1 つとカウントする
これは、システムの規模が、過大に評価されないようにするためだろう。少し、具体的な計測の流れをみてみる。
ファンクションの抽出と識別
初めに、ファンクションを抽出、識別する。そもそも「ファンクション」とは、FP 法にもとづいて抽出された AP の『機能』のこと。全部で 5 種類ある。イメージ優先で、超コンパクトにメモしておく。
- データファンクション（DF）：ユーザが認識できる論理データ
- ILF（内部論理ファイル）… 境界内で維持管理*2
- EIF（外部 I/F ファイル）… 境界内から参照のみ
- トランザクションファンクション（TF）：ユーザにとって意味があるデータの入出力
- EI（外部入力）… 境界外から ILF に維持管理
- EO（外部出力）… 境界外に出力（加工あり）
- EQ（外部照会）… 境界外に出力（加工なし）
これらが『機能』。
DF であれば「DFD」,「ER 図」などから抽出し、ILF と EIF を見つける。TF であれば「業務フロー図」,「画面設計書」,「帳票設計書」などから抽出し、EI, EO, EQ を見つける。
ILF, EIF および EI, EO, EQ を見つけたら、それぞれの複雑度を判定し、点数化していく。 複雑度は、Low（低）, Average（中）, High（高）の 3 段階で判定する。ざっくり 3 段階。どうせ一定のブレ幅があるのに、これ以上細かく基準を設けても、手間ばかりかかるからなのだろう。
具体的にどうやるのか、以下に、簡単にメモしておく。
DF の複雑度の判定と点数化
まずは、DF の複雑度の判定から。複雑度は、DET と RET の相関で決まる。間違いを恐れず、この 2 項目のイメージをメモする。
- DET（データ項目数）：ユーザが認識できる、データの項目数*3
- RET（レコード種類数）：データのサブグループの数
データの項目数と、サブグループの数を分けて数えるのは、なんとなく納得できる。いくらテーブルの項目数が少なくても、参照するテーブルのリストが多い場合には、処理が複雑になりやすい*4だろう。
それぞれ計測し終えたら、次の表*5に従って複雑度を判定し、点数化する。
TF の複雑度の判定と点数化
次に TF の複雑度の判定。DF と同様、間違いを恐れずイメージだけをメモする。DF の DET の計測の粒度を考えると、画面や帳票だって、同様に数えると考えるのが自然だろう。
ここで、FTR の考え方が面白い。いくら画面の項目数が多くても、1 テーブルの内容を出力するだけの機能は、小さな機能だ。確かに、要件定義 〜 外部設計あたりのフェーズでは、こうやって複雑度を算出するしかない気がする。
DF の場合同様、それぞれ計測し終えたら、次の表に従って、複雑度を判定し、点数化する。
ちなみに、EQ と EO の複雑度の判定は、全く同じ表を用いる。しかし、EQ よりも EO の方が高い点数がつくようになっている。
複雑度の判定の具体例
例として、次の図のような、帳票を出力する処理における「発注情報の ILF」および「発注書を出力する EO」を考える。これで DET, RET および FTR, DET を計測するイメージがつかめるはず。
ここで、「発注書を出力する」ファンクションが EO になっているのは、発注書に「合計」の欄があり、出力時に演算しているから。ただ、EO と EQ は、どこで線引きするのか、正直、よくわからない。
さて、前述したマトリクスを用いて、FP を計測しよう。「発注情報の ILF」は、DET = 8, RET = 2 なので、複雑度は L（低）。なので、7 FP。一方、「発注書を出力する EO」は、DET = 11, FTR = 3 なので、複雑度は A（中）。なので、5 FP。
せめて、これくらいは、頭に残しておきたい。
