■ちょっと立ち読み
『ソフトウエア見積もりの達人になる（２）〜見積もり数値の持つ意味と扱い方』
◆ＷＢＳ見積もりによる誤差
この点は、前回述べたＷＢＳに基づく計画・管理の弱点の一つでもある。以前、あるＳＩ企業の生産管理の仕事で、Ｃ系言語とＵＮＩＸを使った開発１５プロジェクトで、ＷＢＳのワークパッケージに対して類似見積もりを行い、そのばらつきを計測した経験がある。このときに、結果だけを書くと、ＷＢＳのワークパッケージ単位で
ＷＰの数 誤差
３０以下 １２％
３０〜５０ １８％
５０〜 ４２％
という数字が得られた。
サンプル数がそんなに多くないことと、ワークパッケージの均質性があまり配慮されていないので、この数字を鵜呑みにすることはできないが、注目に値するのはワークパッケージの数が５０を超えると、極端に誤差が出てきていることは注目に値する。感覚的にはこれはお分かりいただけるだろう。
そういったこともあって、ＦＰ法などの（数学）モデルを使った見積もり方法は通常、システム全体に適用することが多い。逆に事例ベースの見積もり方法は、事例適用した際の誤差を考え、見積もり単位を可能な限り小さくして、積み上げていくことが一般的だ（要素分解法などと言われることがある）。ただ、そうすると上に述べたように累積誤差が大きくでてくる。結局、バランスを考えるということになるのだろうが、事例ベースの見積もりは大規模なシステムの開発にはあまり適さないと考えた方がよいのかもしれない。
（2003/07/10号より抜粋）
■７月号（プロセス３） 目次
> 2003/07/03 アクティビティ１ ソフトウエア見積もりの基本手法
◆はじめに
◆一体、何を見積もるのか？
◆ファンクションポイント（ＦＰ）法
◆開発規模の見積もり
◆しかし、見積もりは見積もりである
> 2003/07/10 アクティビティ２ 見積もり数値の持つ意味と扱い方
◆見積もり単位と累積誤差
◆ＷＢＳ見積もりによる誤差
◆オブジェクト指向は見積もりしやすい
◆仕様のあいまいさによる誤差
◆見積もりの詳細化
◆予算配付で見積もりをコントロールする
> 2003/07/17 アクティビティ３ 計画とリスクを明確に区別する
◆見積もり＝見積もり＋調整値＋リスク？
◆何のための計画か
◆計画とリスクを分ける
◆失敗をしたくないという心情
◆コンティンジェンシープランの作り方を工夫する
◆重要なことは戦略性
> 2003/07/24 アクティビティ４ 見積もりの達人になるために
◆見積もりは結果ではない
◆見積もりを作りこむ
◆技術指標を押さえるとは
◆プロセス３に関連するプロジェクトマネージャー養成マガジンの記事
◆プロセス３のまとめ
