ソフトウェア見積り - LOC・FP・COCOMO

ふふ、現場でもそういう場面はあるけれど、それだと当たり外れが大きいでしょう?
だから根拠のある計算方法がいくつもあるのよ。
代表的なのが、LOC法?
とファンクションポイント法?
ね。

そこなのよ。
LOC法は『作る前は正確な行数が読みにくい』『言語に左右される』のが弱点。
そこで登場するのがFP法。
こちらは行数ではなく、画面・帳票・データの入出力といった『機能の数と複雑さ』で測るの。
だから使う言語が変わっても見積もりがブレにくいのよ。

鋭いわね。
FP法は『利用者から見える機能』で測るから、発注側にも説明しやすいの。
簡単な例で感覚をつかみましょう。
検索機能が3個・登録機能が2個・帳票が1個あって、複雑度の重みを足したら合計60FPになったとするわね。
1FP作るのに0.5人日かかるチームなら、工数?
は60×0.5で30人日、と見積もれるのよ。

見積りは1つの方法に頼らないのが大事よ。
ほかにもよく使うのが2つ。
1つは類推見積り?
。
『前に似たのを3か月で作ったから今回も3か月くらい』と、過去の実績から推測するの。
早いけれど、似た事例がないと精度が落ちるわ。

ふふ、いいところに気づいたわね。
もう1つがWBS?
を使った積算見積り。
名前は難しそうだけど中身は素朴で、やることを『大きなかたまり→中くらい→細かい作業』へとどんどん分解した一覧表のことなの。
たとえば文化祭の準備を『装飾』『出し物』『広報』に分け、装飾をさらに『買い出し』『工作』に分ける――あの分け方と同じよ。

『にんげつ』と読むのよ。
人月?
は『1人が1か月でこなす仕事量』を1と数える単位。
だから100人月の仕事は、10人なら10か月、という計算になるわ。

うまいたとえね、まさにそれよ。
最後に整理するわね。
規模を測るのがLOC法(行数・言語に弱い)とFP法(機能の数・言語に強い)。
その規模から工数を導くのがCOCOMO。
手早く出すなら過去実績の類推見積り、じっくり正確にならWBSで積み上げるボトムアップ。
そして工数の単位は人月で、人月の神話に注意――この骨組みを押さえれば見積りは怖くないわ。