ファンクションポイント系見積りのメモ

ソフトウェアの「規模」を見積る。「工数」の見積もりではない。

工数は、見積もった規模を元に、

利用する要素技術の生産性
非機能要求
どの開発プロセスを使うか
管理工数
リスク

などを加味して求めるのかな？

参考書籍

ソフトウェア開発見積りガイドブック―ITユーザとベンダにおける定量的見積りの実現 (SEC BOOKS)

作者: 情報処理推進機構ソフトウェアエンジニアリングセンター
出版社/メーカー: オーム社
発売日: 2006/05/01
メディア: 単行本
購入: 2人クリック: 27回
この商品を含むブログ (5件) を見る

ファクションポイント系見積もりの種類

名前	利用できるフェーズ	誤差	説明
IFPUG	外部設計完了後	小	機能やデータのファクションを数え、重み付けして見積もる。一般にFPと言えばこれを指すと思う。
FP概算法	要求定義後	中	FTRやDETの数値なしで求める。NESMA法のひとつ。
FP試算法	ビジネスモデリング後	大	データファンクションの数のみで求める。NESMA法のひとつ。

どの方法を選ぶか？

フェーズが進むにつれて、より詳細な見積もりが出せるようになるし、必要にもなる。
従って、フェーズに応じて、より精度の高い見積もり法を選択していくのがよい。

利用の例（あくまでもシナリオのひとつです）

ビジネスモデリング（RUPのBMです）完了後
- 規模感を把握し、プロジェクト化するかどうかを決めたい。また、大まかな予算取りをしたい。
- ユーザ企業はFP試算法で超概算見積もりを求める。
要求定義後（RFP発行と思ったらいいかな）
- 発行されたRFPをもとに、ベンダはFP概算法で概算見積もりを行う。選定されたベンダは準委任契約などの従量契約で外部設計に入る。
外部設計後
- 外部設計を元に、IFPUG法を用いて詳細な見積もりを行う。内部設計〜統合テスト位までは委任契約で実施。ベンダ側も過小な見積もりは赤字案件につながるため、情報を集めて詳細に見積もりをする。

IFPUG(International Function Point User Group)法

外部設計完了後に見積もる場合に用いる

参考

手順

1.ファンクションを数える
1.1.トランザクションファンクション（処理の主目的により類別）
アクターとシステム境界とのやり取り（人だけでなく、他システムももちろんアクター）

EI：外部入力：エントリなど
EO：外部出力：何らかの処理を行った上で出力
EQ：外部照合：単純な出力

1.2.データファンクション

ILF：内部論理ファイル：システム内部で保存するもの
EIF：外部インターフェイス：保存せず、参照のみ

なお、機能数は、ユーザから見て意味のある数。ユースケースの粒度と同レベルと考えてよさそう。
また、データは、概念モデルの塊と考えればよさそう。

2.未調整ファンクションポイントを求める
以下の要因により、複雑度を求めて重み付け
2.1.トランザクションファンクション

FTR：関連ファイル数
DET：データ項目数

2.2.データファンクション

RET：レコード種類数
DET：データ項目数

⇒マトリクスはCPM（ Counting Practices Manual）に定められているということだが、見つからない。このサイトが使えそう。

3.調整する
オプション。

NESMA法

設計が完了していなくても、概算工数がだせるように工夫したもの。

FP概算法

要求分析後に用いる。FTRやDETの数値なしで求める。
誤差はあまり大きくない。

データファンクションの複雑度は、すべて「低」
トランザクションファンクションの複雑度は、すべて「中」とする。

FP試算法

ビジネスモデリング後に用いる。
データファンクションの個数のみで見積る。
誤差は大きい。

FP試算値＝35×ILFの個数＋15×EIFの個数

asa nisi masa