「ソフトウェア開発の見積もり2」

最も多く利用されている方法（方法と呼べるものでもないですが・・・）です。

いわゆる概算であり、見積担当者の主観性:「経験（K）、勘（K）、度胸（D）」と技術力に依存するため、精度がまちまちです。
主観性の強い見積もりですので、見積もりの根拠性も薄く、お客様への説明もままならないことがあります。
同様に根拠が薄いため、同一プロジェクトの他のエンジニアへの説明もままならない場合があります。

それでも、熟練者の見積もりは概算法でも説得力があることも事実です。
また、見積担当者の経験や失敗をナレッジベースとしてまとめたりすることで、精度を上げられるのも事実です。

積算法では開発で必要となる作業を洗い出し、その作業ごとの工数を見積もって積み上げます。作業の洗い出しはワーク・ブレイクダウン・ストラクチャー（Work Breakdown Structure）の技法を用います。WBSとはプロジェクト全体を細かい作業に分割していく手法です。
見積もり精度は、WBSによって洗い出された作業項目の細かさに依存します。つまり、作業項目を洗い出せば精度をアップさせることができます。
しかし、欠点としまして洗い出し作業のために見積自体の工数が大きくなり、トータル費用や見積もり提示期間に影響してしまいます。

COCOMO（COnstructive COst MOdel）は、開発規模をソースコード行数(LOC: Line Of Code)で表し、対応工数を見積もります。
簡単に式を示しますと、
[作業量]＝[パラメータ1]×（ステップ数 ＾ [パラメータ2]）
となり、ステップ数とその作業量（工数）に一定の関係式があるという統計的推論に基づいてます。
担当者の経験に左右されない見積もりが得られますが、パラメータの設定が非常に困難です。また、開発もしていないプログラムのステップ数をどう把握するのかという欠点もあります。

オリジナルのCOCOMOは最近のソフトウェア開発環境の動向において、従来型の開発環境ほどには適合しにくくなってきました。
COCOMOIIは、COCOMOを改善し、1990年代から2000年代の開発環境に焦点が当てられた見積もり技法です。

COCOMOIIでは、開発プロジェクトの初期から設計・開発に向けて、3つのモデルがあります。

表1. COCOMOII ３つのモデルの特徴

開発規模はソースコード行数で表し、それを工数に変換する式になっています。さらに、開発規模を推定するために、ファンクションポイントを用いて推定する事もできます。また、開発がまったくの新規ではなく、一部のシステムを再利用する場合にも使用できるように調整方法が組み込まれています。

FP法は、開発するソフトウェアの規模をその機能数（Function Point ファンクションポイント）で測ろうとするものです。機能を画面入力や帳票出力、使用ファイル、外部インターフェースの数によって測ろうという考え方です。
ユーザーにも分かりやすく、合意を得やすい見積もり手法です。但し、基準値の実績データ収集・評価基準が必要です。FP法にはいくつかの計測手法があり、IFPUG法やCOSMIC-FFP法という計測方法が存在しています。

信頼性・客観性を持ち合わせている手法ですが、欠点もあります。
FP法の算出は、要求仕様書から行います。つまり、要求仕様書が確定する以前には算出できません。また他の手法に比べると見積もり作業工数もアップしますし、見積もり手法の習得にも時間が必要です。