まずRFP(Request For Proposal:提案依頼書)から読み取れる要素をまとめましょう。
次の表は、RFPと顧客へのインタビューの結果のダイジェストを、機能の広さ、タスクの深さ、品質の重さにまとめたものです。記事で紹介するために圧縮してまとめたことをご了承ください。
機能の広さ |
---|
入室時タッチ機能(クライアントアプリケーション)
|
端末管理機能(クライアントアプリケーション
|
Web管理画面機能(Webシステム)
|
そのほかの機能
|
タスクの深さ |
---|
インフラの選定・構築も施工範囲 |
クライアント機能のパフォーマンスが重要なため、パフォーマンステストと継続運用テストが重要(レポートも必要) |
オンサイト顧客ではないため、設計書・仕様書を充実させる必要があり |
品質の重さ |
---|
クライアント機能
|
Web管理画面機能
|
可用性
|
さて、これらの要素を、早速複数の見積もり手法を利用して流し込んでいきましょう。
概要設計の結果 | |
---|---|
実装行数 データベース点数、項目数 |
テーブル数9 |
画面点数、項目数 | 管理画面30画面程度 |
クライアント画面(非常に複雑) |
3画面程度(普通は8画面程度) |
開発後に計測したこのプロジェクトの実費用は、コストが12人月程度、作業人員数が2?4人体制で、工数が15人月でした。
機能の広さから見積もりを計測するFP(ファンクションポイント)法、タスクベースのアプローチによるタスク積み上げ法による見積もり、ユースケースポイント法による見積もりを比べてみます。
FP法自体の詳細な説明は省きます。このFP法ですが、非常に多数に枝分かれし、さまざまな方法が並存しているのが実情です。
FP法の基本は、インターフェイスに着目し、その数を数えることにより機能の広さを見積もる方法です。つまり、「画面の数は何枚、想定されるデータベーステーブル数はいくつ」という数を数えることからファンクションポイントという見積もりのポイントを割り出します。
さらにこの方法では、画面を「複雑」「平均的」「簡易」などの段階に分けていきます。
FP法のメリットとしては、次のようなことが挙げられます。
逆にデメリットとしては、次のようなことが挙げられます。
特に多くの場合に問題になるのが、Dでしょうか。外部設計がある程度進んだ段階では、見積もりが比較的正確にできますが、本格的にプロジェクトがスタートしていないような初期の「ザックリと見積もりをお願いします」といわれるようなケースなどでは用いにくい手法です。
また、プロジェクトが大きくなると画面やデータベースのおよその数が分かるまでに多くの時間とコストを費やしてしまいます。
それでは次回、具体的な計測方法や見積もりを行っていきたいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.