ファンクションポイント法

ちょっとまじめに考えてみる。


まずは次のように決め撃ちで考えてみる。
ソフトウェア＝ファンクションの塊
ファンクション＝ざっくりと入力から出力まで面倒を見るひとつの機能。
ざっくりと、と、書いたが、「ひとつの機能」というのが難しい。
それは、「クラス」なのか、それとも、「メソッド」なのか、それとも、ひとつのプロセス単位なのか。
単に「機能」といっても切り方は人それぞれである。
人それぞれ尺度が違うなら均一な見積もり精度を維持するのは難しいじゃないか。
と、なりそうだが、それを防ぐためにファンクションごとに「レコードの種類の数やデータ項目数など」から難易度を規定する。
これをファンクションポイントという数字に置き換える。
このスコアの合計値の大小で顧客は自分の要求した使用に対する見積もり額の妥当性を図る。

---

ざっくり書くと上のような感じだろうか。
（昔、情報処理の対策本で一夜漬けしたときしか見たこと無いので自信が無いが）


例えば、デザインパターンでInterpreterのような手間がかかる割に同じような
名前が連続して出てくるパターンを使っていた場合、そこに手を入れたい場合、
どう見積もれば良いのだろう？
例えばサブジェクトに手を入れるとする。
さて、この場合ファンクションとはどこからどこまでなのだろう？
相手が納得してもらえるならクラス単位まで分けたいのだが、どうだろう？
そうだよな、だって機能ごとの塊として「クラス」を定義したんだから。
ただ、すべてのクラスがそうだ、とは言えないんだよな。
と、か、思ったが、客には詭弁に聞こえるだろうか。