ソフトウェア見積り勉強会 第５回 第４章 見積り誤差はなぜ起きる？ 永和システムマネジメント 近藤 修平.

Presentation on theme: "ソフトウェア見積り勉強会 第５回 第４章 見積り誤差はなぜ起きる？ 永和システムマネジメント 近藤 修平."— Presentation transcript:

1 ソフトウェア見積り勉強会 第５回 第４章 見積り誤差はなぜ起きる？ 永和システムマネジメント 近藤 修平

2 ⇒ よくわからなかったので具体的に言い換えると？
４章 見積り誤差はなぜ起きる？ たくさんの死屍累々然とした症例 見積り誤差を引き起こす原因 見積るプロジェクト自身に関する不正確な情報 プロジェクトを遂行する組織の能力に関する不正確 な情報 正確な見積りをサポートするプロジェクト内の過剰 な混乱（つまり移動するターゲットを見積もろうと すること） 見積りプロセス自体から発生する不正確さ ⇒ よくわからなかったので具体的に言い換えると？

3 4.1 見積りの不確実性の原因 ソフトウェア開発のゴールって？ コストとスケジュールと機能の組み合わせで決まる
必要な機能を満たすために必要なコストと期間を見 積もる 確定した予算やスケジュールの元に、どれだけの機 能を実現可能か見積る いろいろバリエーションはあるよね 要求アクティビティからリリースまでの不確実性 てんこもり！！ ⇒ ゴールの話とどうつながるの？

4 4.2 不確実性のコーン(1/2) 不確実性のコーンとは？ プロジェクトが進行するに従ってどのように見積り が正確になっていくかを表した物
スコープの話 工数、コスト、機能あるいはそのいくつかを組み合 わせてプロジェクトの規模を表す方法 私が普段使っているのとはちょっと違うニュアン ス？（たいていは要求や機能を指すことが多い？）

5 4.2 不確実性のコーン(2/2) 残念！！ 「見積り作業にもう１週間かけたら、不確実性を少なく するように詳細化できますか？」
ソフトウェア定義（要件？）の詳細化レベルに依存 する 見積りにばらつきがある≒ソフトウェアプロジェク ト自体にばらつきがある 見積りの正確性はプロジェクトの最初の３０％ぐらいで 急速に改善される！ な、なんだってーっ！！

6 4.2.1 コーンに勝てるか？ 本書の図は考えられうる限りの最良の正確な見積りでし た。
これより悪くなることはあっても良くなることはな い！！（断言）

7 ⇒ コーンを狭くする為の具体的な意志決定って何がある？
4.2.2 コーンはひとりでには狭くならない コーンが収束するのは、ばらつきを取り除くための意志 決定をしたときだけ 製品ビジョンを定義する 要求を定義する ユーザインタフェースを定義する ⇒ コーンを狭くする為の具体的な意志決定って何がある？

8 4.2.3 ソフトウェア見積りに不確実性のコーンを組み入れる
シングルポイントな見積りに対抗するには？ 　(1) 最もありそうな見積りでスタートして、係数を使っ て幅を持たせる（コーンの範囲を使ってみる） 　(2) 「いくらかかる」と、「いかに不確実か」を別々に 見積もる ⇒ どちらがお好みですか？

9 4.2.4 不確実性のコーンとコミットメントの関係 コーンの早すぎる段階でのコミットメント 有意義なコミットメントは不可能
できるだけコミットメントを遅らせる ん？どこかで聞いたような…

10 4.2.4 不確実性のコーンと反復型開発 イテレーション内で要件定義から始めるやり方 サイクルが短い場合はタイムボックス的になる？
長期の予測をするには不利

11 4.2.4 不確実性のコーンと反復型開発 イテレーション内で要件定義から始めるやり方 サイクルが短い場合はタイムボックス的になる？
長期の予測をするには不利

12 完全な反復に代わる 方法は 反復しないことではなく より少ない反復か 別の反復だ

13 4.2.4 不確実性のコーンと反復型開発 イテレーション内で要件定義から始めるやり方 サイクルが短い場合はタイムボックス的になる？
長期の予測をするには不利 完全な反復に代わる方法は反復しないことではなく、よ り少ない反復か、別の反復だ。 いわゆる要件定義フェーズあたりはシーケンシャル にやって、開発は反復すればいいんじゃない？

14 4.3 混乱した開発プロセス 今までは適正にコントロールされたプロジェクトにおけ る不確実性の話
様々な要因でしばしばプロジェクトは混乱するよね プロジェクトの混乱における２つの共通点 ばらつきを引き起こす 対応策は良いプロジェクトコントロール ⇒ コントロール不能なプロジェクトを正確に見積もる ことは不可能。先に混乱を修復すること。

15 4.4 不安定な要求 要求変更が引き起こす見積りの課題 要求が不安定であること≒プロジェクトの混乱 要求変更の際に再見積りされないこと
要求が不安定な時には良い見積り技法よりも、プロジェ クトコントロール

16 4.4 要求の増大を見積もる 要求の増大、変更の許容量をあらかじめ見積りに組み込 む
※ COCOMO = COnstructive COst MOdel 開発するソフトウェアの行数を把握し、その行数を開発工数に換算する手法。 COCOMO IIはCOCOMOにFP法の概念を取り入れた感じ