ユースケースポイント法(UCP法)

見積もりにおける手法の1つ。

有名なFP法はデータ項目数(DBのテーブルやファイルの項目数)と入出力の数を手がかりにシステムの規模を見積もるが、UCPはUMLでいうクラス図を元に規模を見積もる方法。

分析クラス図までを作れれば、UCP法で見積もりしやすいだろう。

分析クラス図をベースにしたポイントを「未補正UCP」とし、さらに技術的な複雑度、環境的な複雑度をもとにした係数をかけることで「補正後UCP」ができあがる。

あとはFP法と同じように「1ポイントは何時間(または人月)かければ消化できるか」=生産性係数をかけることで工数の見積もりにすることができる。


UMLを主に開発するプロジェクトでは非常に重宝されそうなこの手法だが、問題点を感じないわけではない。


この手法で感じる問題点は、FPと同じように「生産性係数をいくつにするんじゃい?」という点なのだが、UCP法を考えたGeri Schneiderさんによると普通のプロジェクトならば生産性係数は20時間らしい。
(つまり1UCPの機能あるいはシステムであれば20時間で作れるであろう、と。)

しかしながらこのUCP法はまだ日が浅いためか、Geriさんの考えるプロジェクトが私の周りと一致しずらいのか、20時間で本当に大丈夫か?という不安がいつもある・・・。
(事実、20時間で工数に変換すると「大丈夫かなぁ・・・」という工数が出てくる)

また、技術要因はさることながら、環境要因が曲者と思う。

なぜならば、環境要因は「採用するプロセスの習熟度」「モチベーションの有無」「プログラミング言語の難しさ」などなど、非機能要件的な要素を先に係数として含めてしまう仕組みになっており、これをどう扱うかが実際に使おうとすると非常に悩ましい。

とはいえ、個人的に分析クラス図は頭のなかで思い浮かびやすいUMLであり、これからもお世話になるはずなので、まずはUCP法の生産性係数はいくつが望ましいのか、周りからデータ収集を地道にがんばるしかないか。


■参考
■オブジェクト倶楽部
http://www.objectclub.jp/

■ITpro
http://itpro.nikkeibp.co.jp/article/COLUMN/20060811/245759/

コメント

このブログの人気の投稿

COCOMO(工数と工期)

iOSアプリのインストール日時を取得する