初めに
http://blogs.yahoo.co.jp/dk521123/33505512.htmlで工数見積もりについて記載したが、今回はファンクションポイント法に絞って記載する ※注意 * ソフトウェアの「規模」を見積りで、「工数」の見積もりではない。
ファンクションポイント法(Function Point, FP)
* アプリケーションにおける「外部入力」「外部出力」「内部論理ファイル」 「外部インタフェースファイル」「外部照会」の五つの要素の個数を求め、 それぞれを重み付けして集計し、その集計した値がソフトウェア開発の規模に 相関するという考え方に基づいて，開発規模の見積る。 * 仕様をベースにして、プログラミング言語に依存せず、 開発対象となるシステムの“機能”の規模を『FP』という単位で計測すること
メリット・デメリット
メリット
1) 開発初期段階での概算が可能 2) エンドユーザが認識可能な計測法である(ユーザ目線での機能洗い出しを行っているから) 3) 言語やツールに依存しない 4) 国際標準されている方法
デメリット
1) 要件で表現できないロジックの複雑さなどは、見積もりに反映しづらい 2) 技術要件や品質要件などの非機能について、見積もりに反映しづらい 3) 尺度が荒い(3段階)ので、機能ごとの重要度が表現しづらい 4) モジュール単位や画面単位などは表現できない
FPの算出手順
* 正式なIFPUG法(International Function Point Users Group「イフパグ」と呼ぶ)ってのがあるが、ここでは、IFPUG法で言う「未調整FPの算出」のみを行う(どうせ調整済FPにしても推奨されてないらしいし)1) 計測範囲とアプリケーション境界を設定する 2) データファンクションの計測 3) トランザクションファンクションの計測 4) FPの算出
1) FP計測タイプを決定する
* それぞれで計測範囲が異なる
1-1) 新規開発FP計測（Development Project Function Point Counting）
* 対象：新規開発＋導入 * 実施フェーズ：要件定義フェーズで実施
1-2) 機能拡張FP計測（Enhancement Project Function Point Counting）
* 対象：拡張機能＋導入 * 実施フェーズ：保守・運用
1-3) アプリケーションFP計測（Application Function Point Counting）
* これはいいかな。やる暇ないだろうし* 対象：システム全体 * 実施フェーズ：導入後
2) データファンクションの計測
データファンクション
(1) 内部論理ファイル(ILF;Internal Logic File) => システム内部で使うファイル、DBで変更があるデータ (2) 外部インターフェイス(EIF;External Interface File) => 保存せず、参照のみのデータ
3) トランザクションファンクションの計測
トランザクションファンクション
(2-1) 外部入力(EI;External Input) => 外部データによる内部ファイルの更新 (2-2) 外部出力(EO;External Output) => 何らかの処理を経て外部に情報出力 (2-3) 外部照合(EQ;External Inquiry) => 単純な検索で外部に情報を提供
メモ
「実践!事例で学ぶファンクションポイント法―発注者も受注者もなっとく!ソフトウェアの規模が測れる手法」 が解かりやすくて良かった。
補足：理解度チェック
* 理解できたか以下の問題をやってみるといいかもhttp://www.fe-siken.com/kakomon/14_aki/q55.html
http://kanauka.com/kakomon/pm/h23t/007.html
http://www.ap-siken.com/kakomon/25_aki/q51.html
参考文献
http://monoist.atmarkit.co.jp/mn/articles/1110/13/news007.htmlhttp://monoist.atmarkit.co.jp/mn/articles/1111/16/news008.html
