ソフトウェア見積り
- 作者: スティーブマコネル,久手堅憲之,Steve McConnell,田沢恵,溝口真理子
- 出版社/メーカー: 日経BP社
- 発売日: 2006/10/07
- メディア: 単行本
- 購入: 31人 クリック: 472回
- この商品を含むブログ (92件) を見る
amazon.comのコンピュータ＆インターネットで，Best Book of 2006 を受賞．著者は，コードコンプリートなどで知られるSteve McConnell．
｢良い｣見積りの定義，見積り誤差の原因，多種の見積り技法の紹介，最後に課題を述べている．参考文献の数からいっても，見積りに対してこれだけ体系立てて網羅している書籍はないのでは．
メモ
見積りとは
- ｢見積り｣｢ターゲット｣｢コミットメント｣はそれぞれ異なるものである
良い見積りとは，プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで，適正な意思決定ができる明確な視点を提供する見積りである．
- 開発者が作り見積りは，一般に実際の工数よりも20〜30％低くなる
- 遅延がプロジェクトをさらに破壊する
過小見積りに対する不利益は，過大見積りに対する不利益よりも深刻である．したがって，完全に正確には見積もれないならば,過小見積りよりも過大見積りの方へ誤ることを心がけた方がよい．
正確な見積りの利点
- 状況の可視化が進む
- 品質が向上する
- ソフトウェア以外の業務部門との連携が良くなる
- 予算が良くなる
- 開発チームに対する信頼が向上する
- 早期にリスク情報が得られる
見積り誤差の原因
- 見積りの有効数字の桁数(精度)を，見積りの正確性と一致させる．395.7日よりも1年，13ヶ月．
- 不確実性のコーン(円錐)
不確実性のコーンがひとりでに狭くなると思い込むのはやめよう．プロジェクトからばたつきの原因を取り除いて，コーンを狭くしよう．(製品定義，詳細な要求，UI設計…)
アクティビティの見落とし
- 提示された要求だけでなく，暗黙に示されている要求や非機能要求，つまりすべての要求を含めること
- 単にコーディングとテストだけでなく，必要なソフトウェア開発アクティビティをすべて入れること
- 新規メンバの立ち上げ/指導
- SCM，ビルドサーバ，要件管理ツール，スクリプトなどの保守/管理
- 新しい開発ツールの学習
- ユーザドキュメント，テクニカルドキュメントの入力/レビュー
- デモ
- 計画，見積り，アーキ，デザイン，コード，テストケースのレビュー
- 間接アクティビティ
- 休暇，祝日，病欠
- 研修
- 全社/部署Mtg
- 新PCのセットアップ
- トラブルシューティング
- 規模の不経済：コミュニケーションパスが急激に増加する結果，プロジェクトの工数もプロジェクトの規模が増えるにつれて急激に増加する．直線的ではなく指数関数的に．
見積り技法で考慮すべきこと
- 見積りの対象
- プロジェクトの規模
- 開発スタイル(プロセス)：シーケンシャル，反復型
- 開発ステージ(フェーズ)
- 正確性
見積り技法
- 数えて，計算して，判断する
- 補正と過去のデータ
- プロジェクトの終わりよりも，進行中にスナップショットを周期的に収集するとよい
- 専門家の判断
- 粒度：タスクレベルで見積りを行うならば，長くても2日程度の工数のタスクにまで見積りを分解する．1/4日，1/2日，1日といった粒度でおこなうとよい．
最良のケースと最悪のケースの見積りを作成して，起こり得るすべての範囲の結果について考えるきかっけにしよう
-
- 見積りチェックリスト(P117) 必見
- 分解して，また組み立てる
- 類推見積り
- 代替指標による見積り
- 専門家グループによる判断
- グループレビュー
- 広域デルファイ法
- ソフトウェア見積りツール
- COCOMOⅡ http://sunset.usc.edu/research/COCOMOII/index.html
- Construx Estimate http://www.construx.com/estimate/
再見積りを実践しよう．
プロジェクトの進行に従って，それほど正確でない見積りアプローチから，より正確な見積りアプローチへと移行しよう．
具体的な開発タスクを配分して割り当てる準備ができしだい，ボトムアップ見積りに切り替えよう
-
- プロジェクトのステークホルダには，前もって再見積りの計画を伝えよう
標準化された見積り手順
- 英語版ですが，DLできます．http://www.stevemcconnell.com/Estimation-17.pdf
見積りの課題
- LOCやファンクションポイントなどの簡単な規模の指標は，共通する根本的な問題がある．それは，1次元の指標から多面的なものを測定すれば，どうしても誤差が生じることだ．
スケジュールの見積りを短縮する場合は，必ず工数の見積りを増やすこと．
スケジュールの見込み値を25%以上短くしてはならない．すなわち，見積りを不可能ゾーンに入れてはならない．
- チームが大きいほどオーバヘッドは大きい
- スケジュールが短いほど，平行作業は増える．オーバーラップが多いほど，作業の1つが他の不完全な作業に影響される可能性/やり直しの可能性が高くなる．
- ｢顕在化したリスク｣(RE：Risk Exposure リスク重大度×発生確率)とはリスクの想定値なので，スケジュールに想定すべきである．
