見積もり

百里を行く者は九十里を半ばとす - 諺

見積もりについて。

ブルックスのスケジューリング

ブルックスは過去数年間、次の目安を使ってスケジュールを上手に運用してきた。

1/3 計画 (詳細でしっかりした仕様を作成することを含む)

1/6 コーディング

1/4 単体テストおよび初期システムテスト

1/4 すべてのコンポーネントを統合して行うシステムテスト

テストにはスケジュールの 1/2 を充てることが望ましい。しかしテストにスケジュールの 1/2 を充てていないプロジェクト、システムテストに充分な期間を割り当てていないプロジェクトが、ほとんどであるのが現実である。特にシステムテストに充分な時間を割り当てないと、スケジュールの最後になってようやく人々がスケジュールに問題があると気づくという、悲惨な結果をもたらす。システムテストにおけるスケジュールの遅延はコストが非常に高くつく。システムテストに充分な時間を割り当てることがきわめて重要である。

http://ja.wikipedia.org/wiki/%E4%BA%BA%E6%9C%88%E3%81%AE%E7%A5%9E%E8%A9%B1

過去のデータ

■ソフトウェアの定量的計測

ステップ：空行・コメント行を含まない
行　　　：全ての行数

●プロジェクトＡ（ASP・ActiveX DLL）

DLL・EXE        118ファイル 68173ステップ   133932行    平均1135.0行/ファイル
ASP・HTML・JS   238ファイル 60194ステップ   104405行    平均438.7行/ファイル
※HTML・JSは合計で1000～2000行程度

設計仕様書433ページ(word)
DBテーブル数100個

●プロジェクトＢ（PHP）

PHP 82ファイル  ?ステップ   20301行 平均246.7行/ファイル

基本設計書：不明
DBテーブル数14個

●プロジェクトＣ（Java）

Java    15ファイル  7353ステップ    10378行 平均
JSP 56ファイル  22424ステップ   24969行 平均
HTML    10ファイル  1445行

基本設計書：118ページ
DBテーブル数24個

見積り方法の知恵

カレンダーを目の前に置く

n人月という工数を出すとき、普通は開発項目ごとに人日を出すかもしれない。
しかし、日数だけで考えていると土日や週の感覚がなくなってしまいがちな気がする。
そこで、カレンダーを目の前において「この日からこの日まででこの項目」と
考えると、実際にできるかイメージがわきやすくていいかもしれない。
もちろん、開始日がわかっていない段階では日付は実際と異なっていて構わない。