 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| 類推見積 | ||||||||||
|
過去の経験や事例を基に、おおよその判断から見積りをするものです。筆者は、この方法をKKD（経験・勘・度胸）手法などと呼んだりしています。技法とは呼べない代物ですが、経験豊かな技術者が用いると意外に正確な見積りがでます。 筆者もなんどもその正確性に驚いた経験があります。しかし、経験と勘が必要になりますので、本連載のテーマである「何をどこまで提示すれば開発の見積が可能になるか」の検討には利用できません。 |
||||||||||
| ボトムアップ見積 | ||||||||||
|
一般にいわれるボトムアップ見積は開発タスクをWBS（Work Breakdown Structure）に分解して、これを積み上げる方式ですが、筆者は、画面・帳票やバックエンドまたはバッチプロセスの数から、難易度別に工程別の係数をかけて積み上げるものもボトムアップ見積に含めて考えます。 そして、これがもっとも多くの開発ベンダーで実施されている見積方法なのではないでしょうか。ただし、この方法は積み上げ型であるがために、どうしても費用が多めになりがちであることを付け加えておきます。 この技法は何に基づいて見積りを算出するかが比較的はっきりしています。元になる要素は次の3つしかありません。
表2：ボトムアップ見積のボトムアップ要素 これらの要素を要件定義前にはかる場合、業務のイメージがわかれば、画面や帳票の数はある程度想定できますが、バックエンドまたはバッチプロセスの数というのは少々難しいということになります。また、難易度というのも少々アバウトな感じで、どのように基準を作るかなど難しい問題があります。 通常、この要素内容が判明するのは要件定義が終了してからになりますので、先の「要件定義が完了してからでないと見積は提示できません」という開発ベンダーの方の発言がでてくることになります。 |
||||||||||
| 係数モデル見積 | ||||||||||
|
ファンクション・ポイント法（以下、FP法）に代表される数式による係数モデルです。一番客観的でだれが実施しても同じ値が得られる方法であるといっても過言ではありません。 しかし実際には、ファンクション・ポイント（以下、FP）で見積費用や工数に換算するためには、サンプルを多数集めてから開発環境による係数を設定しなければならないなど、様々な課題があります。しかし、何を元にFPを計算するのかというのは非常に大きなヒントになると思われます。 FP法の詳細は割愛しますが、非常に大雑把にFP法を捕らえると、FPの算出元となる要素は次の表3によって決まります。つまり、どのように費用や工数に換算するかとは別にして、これらの要素が決まればFPの算出は可能になるということです。
表3：FPの算出元となる要素 この結果を、ボトムアップ見積と対比してみます。ボトムアップ見積では、画面・帳票やバックエンドまたはバッチプロセスという処理をまとめたものを数えていましたが、FP法では、より細かく処理を分解しています。 これに加えて、内部論理ファイル数や外部インターフェース数を取り上げています。実は、この違いがボトムアップ見積での難易度に相当する部分であると考えられます（実際にはFP法にも複雑度など難易度に相当する係数が残っています。しかし、ボトムアップ見積の難易度をより細分化しているものということができそうです）。 しかし、画面・帳票数はともかく、このような分解した処理数などは要件定義や設計が終わらなければわからないということがあるかと思います。これでは結局、要件定義完了後にしかRFP作成ができないという話に戻ってしまいます。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
