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

Slides:



Advertisements
Similar presentations
2004 年新潟県中越地震と スマトラ沖巨大地震の 震源で何が起こったのか? 八木勇治 (建築研究所・国際地震工学セン ター)
Advertisements

プロジェクト名称 Inception Deck (Project Charter) 201X.XX.XX.
CMU2005 海外エンジニアリングワークショップ参加報告書 1 「真の要求を見極めろ!」: teamB 要求定義をどう捉えるか ● 要求定義とは何か? 製品には、顧客の望むことを正しく反映させる必要がある。 そのために必要なものが要求仕様である。 すなわち、要求仕様とは、顧客と製品を結ぶものであり、これを作ることが要求定義である。
34-2 今 日 の ポ イ ン ト今 日 の ポ イ ン ト 現代社会とストレスと糖尿 病 1.1. ストレスによる 血糖コントロールへの影響 2.2. QOL障害によるストレ ス 3.3. 糖尿病とうつ 4.4. ひとことアドバイス 5.5.
1 EASE プロジェクトにおける EPM ( Empirical Project Monitor) を用いたプロジェクト管理デモ 奈良先端科学技術大学院大学 産学官連携研究員 松村 知子 2005 年 9 月 30 日 JISA 経営者セミナー.
経営の科学 第 6 回 社会工学域 竹原 浩太. 今後の予定 10/22 企業金融とは何か(今回) 10/29 企業の資金調達の多様化 11/5 企業の最適資本構成 11/12 信用リスク 11/19 期末試験.
プロジェクトとは.
「ベースボール統一球は変わったのか」を検証,予測する。
第2章 機械の強度と材料 機械の必要条件 ★壊れない ★安全である ★正しく機能する そのためには・・・ ★適切な材料を使う
数理統計学  第9回 西山.
点対応の外れ値除去の最適化によるカメラの動的校正手法の精度向上
フィッシャーの三原則 実験につきまとう誤差をいかにして制御するか
機能実現期間の測定による プログラマ能力の実験的評価
最強組織の法則 ー新時代のチームワークとは何かー
学生のシステム提案における 見積もり法提案 湯浦研究室4年 飯田真矢.
東京大学工学部 丁友会学生委員会 学生委員長 竹内健登
OJT研修 「テスト実施、テスト設計の技術習得」 日時: 8月22日(月)  場所: 本社5階.
Pattern Recognition and Machine Learning 1.5 決定理論
計測 と 見積り ~ ソフトウェア開発のよりよい見積りのために ~ biac
3-1システム戦略 3-1-3ソリューションビジネス (Point) ・代表的なサービスを通じ、ソリューションの考え方を理解
テスト段階.
事業計画 発表者名 | 会社名.
(民主主義の当事者としての)市民による社会運営
3.労働時間の弾力化と課題 ◇新しい労働時間制度の導入◇ ◇弾力的な労働時間制度とは◇ 1987年、93年、98年
プロセス制御工学 6.PID制御 京都大学  加納 学.
プロトタイプ PoC プロジェクト概要 6 weeks ソリューションの検討 ビジネスの理解 プロトタイプの範囲 本稼動 システム検討
プロジェクトの選択基準 と CBAの役割と限界
わかりやすいマルチスライスCTにおける画像再構成
構成管理 構成管理とは、ソフトウェア開発に於ける成果物をある時点で凍結し、 以降の変更を管理する事をいう
~企画~ GO,桑田,ヒルズ.
? ? ? ? ? ? ? ? 多変量解析とは? 問題となっている現象 ●問題の発生原因がわからない(因果関係)
プロジェクトの選択基準 と CBAの役割と限界
繰り返しのない二元配置の例 ヤギに与えると成長がよくなる4種類の薬(A~D,対照区)とふだんの餌の組み合わせ
要約 きりん、まぐろ、PB.
導入段階.
ソフトウェア工学 第五回 知能情報学部 新田直也.
顧客獲得.
設計方法について、当社では「そうなっていない事」が多いように思った。この講習会を通して改善されればもっと良い製品作りができると思う。
~新たなソフトウェア開発の手法~ 発表 土屋俊介
プロジェクト管理ソフトの群雄割拠をどうやって勝ち抜くか?
日程計画 (scheduling) 大規模なプロジェクトの日程を計画し、その進行を管理する手法。
コードクローンの動作を比較するためのコードクローン周辺コードの解析
計測工学 -誤差、演習問題 計測工学(第6回) 2009年5月26日 Ⅱ限目.
設計工学 内容 目的 ★もの作りのための設計 ★実際の現場で役立つ設計 ★機械設計や機械作りの楽しさを知る。 ★工学的な理屈を考える。
シリーズ:著者の回答  質問 (Oh社、第1回受講者)
第3回  業務プロセスとERP.
計測 と 見積り ~ ソフトウェア開発のよりよい見積りのために ~ biac
競争の戦略 マイケル・E・ポーター 藤井 海太.
第7章 不確実性の処理 :期待値、感度分析、情報の価値
多層的な知人関係に基づく 自己情報コントロールの実現
ビジネス プロジェクトの計画 発表者名 | 会社名.
誤 差 誤差 = 測定値 - 真値 ・真値は神様だけが知っている。 ・ばらつきの程度を表す意味が薄い。
コードクローンの理解支援を目的としたコードクローン周辺コードの解析
UMLの概要とオブジェクト指向の基本概念
超短期トレードで生き残るためのテクニックと考え方
「アルゴリズムとプログラム」 結果を統計的に正しく判断 三学期 第7回 袖高の生徒ってどうよ調査(3)
企業システム戦略を成功させる! ドキュメント・レビュー実践法 企業システム戦略家 青島 弘幸.
TOC 制約理論のひろば Copyright , Toshio Sasaki All Rights Reserved
製品またはサービスの販売 サブタイトル.
保守請負時を対象とした 労力見積のためのメトリクスの提案
7章 不確実性の処理 期待値、感度分析、情報の価値 09/05/28.
パイプラインとは何か? マイクロプロセッサ(MPU)の高速化手法の一つのこと。
卒業テーマの発表 在庫量の効率管理    卒業テーマの発表        ------在庫量の効率管理      a6p21502 Huang Ping.
開発作業の形式化に基づく プロセス評価 松下誠 大阪大学.
設計工学 内容 目的 ★もの作りのための設計 ★実際の現場で役立つ設計 ★機械設計や機械作りの楽しさを知る。 ★工学的な理屈を考える。
派遣先企業の皆様へ ご協力のお願い 聴くチカラ 伝えるチカラ 遂げるチカラ 律するチカラ
情報数理Ⅱ 第10章 オートマトン 平成28年12月21日.
テクニカル・ライティング 第4回 ~文章の設計法「KJ法」について~.
情報処理の概念 #0 概説 / 2002 (秋) 一般教育研究センター 安田豊.
FSE/ASE勉強会 A10:Software Maintenance II
Presentation transcript:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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