計測 と 見積り ~ ソフトウェア開発のよりよい見積りのために ~ biac

Slides:



Advertisements
Similar presentations
CMU2005 海外エンジニアリングワークショップ参加報告書 1 「真の要求を見極めろ!」: teamB 要求定義をどう捉えるか ● 要求定義とは何か? 製品には、顧客の望むことを正しく反映させる必要がある。 そのために必要なものが要求仕様である。 すなわち、要求仕様とは、顧客と製品を結ぶものであり、これを作ることが要求定義である。
Advertisements

1業務の実施方針等に関する事項 【 1.1 調査内容の妥当性、独創性】  事業の基本方針、目的及び調査内容 記述内容 ・仕様書を踏まえて、本事業の基本方針、目的について具体的に記述する。 ・仕様書を踏まえて、本事業の内容について具体的に記述する。 ・当局が提示した内容以外に、当該事業を効果的・効率的に実施するための新たな提案がある場合、その内容を具体的に記述する。
燃料デブリ臨界管理技術の開発( FP ガンマ線検出器システム 幾何学的効率計算コード及び技術サポート) 入札提案書 © 日立 GE ニュークリア・エナジー ( 株 ) 2013 【 1 事業の内容及び実施方法】 1.1. 事業内容(実施方法を含む) 1 . 1 . 1 幾何学的効率計算コード  事業内容(実施方法を含む)
1 EASE プロジェクトにおける EPM ( Empirical Project Monitor) を用いたプロジェクト管理デモ 奈良先端科学技術大学院大学 産学官連携研究員 松村 知子 2005 年 9 月 30 日 JISA 経営者セミナー.
背景 ソフトウェアの大規模化・複雑化 生産性と品質の向上 ↓ オブジェクト指向分析設計の適用 開発ツールの投入.
プログラマのレベルアップ.
【1 事業の内容及び実施方法】 1.1. 事業内容(実施方法を含む) 1.1.1 FPガスγ線による再臨界検知システム開発補助
【1 事業の内容及び実施方法】 1.1. 事業内容(実施方法を含む) 破断試験の計測準備
Rapid紹介 開発手法(Rapid活用)
OJT研修 「テスト実施、テスト設計の技術習得」 日時: 8月22日(月)  場所: 本社5階.
ソフトウェア見積り勉強会 第5回 第4章 見積り誤差はなぜ起きる? 永和システムマネジメント 近藤 修平.
実証分析の手順 経済データ解析 2011年度.
計測 と 見積り ~ ソフトウェア開発のよりよい見積りのために ~ biac
3-1システム戦略 3-1-3ソリューションビジネス (Point) ・代表的なサービスを通じ、ソリューションの考え方を理解
【1−1.開発計画 – 設計・開発計画】 システム開発計画にはシステム開発を効率的、効果的に実行する根拠(人員と経験、開発手順、開発・導入するシステム・アプリケーション・サービス等)を記述すること。 システム開発の開始から終了までの全体スケジュールを記載すること。 アプリケーション機能配置、ソフトウェア、インフラ構成、ネットワーク構成について概要を示すこと。
事業計画 発表者名 | 会社名.
ソースコード品質概論 なぜソースの品質を追求するのか
進捗管理 1.進捗度算出 (1)進捗尺度 進捗把握の単位は、細分化されていることが望ましい。 可能ならば1人1週間の作業量を1単位とする
【1 事業の内容及び実施方法】 1.1. 事業内容(実施方法を含む) 原子炉建屋に対する外部事象の調査
要員管理 要員の質、量、配置、作業状況を管理する 一般的な注意点を下記に示す (1)組織 ・組織構成を明快にする -指示命令系統
開発流れ.
CSP記述によるモデル設計と ツールによる検証
【1 事業の内容及び実施方法】 1.1. 事業内容(実施方法を含む) 竜巻条件の設定作業
【1.1事業の目的・内容について】 4.2 (別紙1) 提案書雛型 内容及び達成目標 記述内容

~企画~ GO,桑田,ヒルズ.
平成30年度観光地域動向調査事業「那覇空港における二次交通利用動向調査」
【1 事業の内容及び実施方法】 1.1. 事業内容(実施方法を含む) フラジリティ検討用解析モデルの作成
2016年度秋期 成果発表会 2016年11月25日 大阪開発センター 技術一部 畑中 龍樹.
平成30年度 那覇空港における二次交通としての路線バス等の利用促進に関する調査・検討業務
【1.1 事業(調査)目的】 1 8.1 (別紙1) 提案書雛型 本事業(調査)の目的について 記述内容
【1 事業の目的、内容及び実施方法】 1.1 事業目的
プログラム実行履歴を用いたトランザクションファンクション抽出手法
【事業名】 【事業代表者】㈱○○ ○○ 【実施予定年度】平成30~○年度 平成30年 月 日 (1)事業概要
【事業名】 【事業代表者】㈱○○ ○○ 【実施予定年度】平成29~○年度 平成29年 月 日 (1)事業概要
プログラム実行時情報を用いたトランザクションファンクション抽出手法
ソフトウェア工学 第五回 知能情報学部 新田直也.
2016年11月25日 大阪開発センター 技術1部 深田 健太 アプライアンス&デジタルソリューション株式会社
ソースコードの変更履歴における メトリクス値の変化を用いた ソフトウェアの特性分析
製造準備段階における 工程FMEAの実施と不具合未然防止
ソフトウェアを取り巻く環境の変化がメトリクスに及ぼす影響について
TDDとメソッドの外部設計 テストファーストの秘訣 2009/08 biac.
2010年度 春季成果発表会 岡本 拓也 2010年5月14日 デジタルビジョンソリューション株式会社 新横浜支店 技術部.
ソフトウェア設計検証 研究室の紹介 知能情報学部 准教授 新田直也.
【1 調査の目的、内容及び実施方法】 1.1 調査目的
【事業名】 【事業代表者】㈱○○ ○○ 【実施予定年度】平成30~○年度 平成30年 月 日 (1)事業概要
ビジネス プロジェクトの計画 発表者名 | 会社名.
【1.1 事業(調査)目的】 1 8.1 (別紙1) 提案書雛型 本事業(調査)の目的について 記述内容
障 害 処 理 票 レ トラブル分類 1 設計バグ 2 製造バグ 3 改造バグ 4 DB、OSバグ 5 環境、HWバグ 6 手順バグ
生産性向上 現場のビデオ映像 OTRSは現場映像から、各種シミュレーションを提供し、組織の生産性向上をサポートしています。
1業務の実施方針等に関する事項 【1.1調査内容の妥当性、独創性】
プロジェクト演習 知能情報学部 新田直也.
パッケージソフトウェア利用コンピュータシステム構築委託契約書 パッケージソフトウェア、OS、第三者ソフトウェアの使用許諾契約
1業務の実施方針等に関する事項 【1.1事業実施の基本方針、業務内容等】
TOC 制約理論のひろば Copyright , Toshio Sasaki All Rights Reserved
保守請負時を対象とした 労力見積のためのメトリクスの提案
平成30年度「訪日外国人旅行者受入環境整備緊急対策事業(実証事業分)」沖縄における交通機関への海外決済手段の導入実証事業
【1 事業の内容及び実施方法】 1.1. 事業内容(実施方法を含む) 薬品配管施工設計・保守点検架台製作
【1 事業の内容及び実施方法】 1.1. 事業内容(実施方法を含む) 実規模免震装置の破断試験結果の詳細評価
情報の授業 アプリ等を活用した勉強方法の改善(計画) ・R-PDCAサイクル ・アプリを活用した勉強方法の改善 計画書
システムとソフトウェア評価: 標準化の目的と必要性
平成30年度 交通結節点創出等による利用促進方策 及び最適な公共交通料金の検討に関する調査業務 提 案 書
第1章 現状メソッドの標準化 対象工程を流れる代表品種に対し作業を区分し、時間・頻度を 明らかにして、オペレーションリストを作成する。
【事業名】 【事業代表者】㈱○○ ○○ 【実施予定年度】平成29~○年度 平成29年 月 日 (1)事業概要
【1 事業の内容及び実施方法】 1.1. 事業内容(実施方法を含む) 3方向地震入力の検討条件の設定
株式会社 エーアイネット・テクノロジ 川村廉平
オブジェクト指向メトリクスを用いた 開発支援に関する研究 --- VC++とMFCを用いた開発を対象として ---
【1 事業の内容及び実施方法】 1.1. 事業内容(実施方法を含む) 破断試験のシミュレーション結果の評価
(別紙1) 提案書雛型 那覇空港におけるレンタカー貸渡の 満足度向上のための実証事業 提 案 書                        (日付)                        (企業名)                        (連絡先等)
アジャイル開発プロセス 森口朋広.
Presentation transcript:

計測 と 見積り ~ ソフトウェア開発のよりよい見積りのために ~ biac 2008/09/20 計測 と 見積り ~ ソフトウェア開発のよりよい見積りのために ~ biac わんくま同盟 名古屋勉強会#07 2009/04/11‏

「見積り」 とは 過去の経験に基づいて、未来を予測する技術 ※ 工数・工期の見積りまでは技術。 見積書に記載する金 額は「政治」 2008/09/20 過去の経験に基づいて、未来を予測する技術 ※ 工数・工期の見積りまでは技術。 見積書に記載する金 額は「政治」 すなわち、過去のデータを未来にあてはめるこ と 計測 見積り

見積りの基本 = サイズ ÷ 速度 例) 遠足 注意 出発地点から目的地までの距離 (サイズ) : 8km 2008/09/20 例) 遠足 出発地点から目的地までの距離 (サイズ) : 8km 歩く速さ (速度) : 4km/h 必要な時間は? ⇒ 8 ÷ 4 = 2時間 注意 ここでは、サイズは正確な値。 ぶれる事はない。 速度 (4km/h) は、経験値。 実際にやってみると 、たぶん違う値になる。

見積りの基本 = サイズ ÷ 速度 例) 遠足2 … サイズも推定値 2008/09/20 例) 遠足2 … サイズも推定値 出発地点から目的地までの直線距離 : 8km 実距離の推定 : 折れ曲がり係数(仮称) = 1.5 ⇒ 実距離(推定) = 8 × 1.5 = 12 歩く速さ (速度) : 4km/h 必要な時間は? ⇒ 12 ÷ 4 = 3時間

見積りの精度 ~ サイズ と 速度 ソフトウェア開発の見積り精度を良くするには × 見積り結果だけを精度アップさせよう 2008/09/20 ソフトウェア開発の見積り精度を良くするには プロジェクトのサイズをより精確に見積もること チームの速度 (生産性) をより精確に見積もること × 見積り結果だけを精度アップさせよう 生産性の向上分が計測できない ⇒ 開発者のスキルアップを評価しない サイズの見積り外れ(仕様膨張)を見ない ⇒ 遅延の原因はすべて開発者の責任にされる

閑話休題 (1) : 遅れを取り戻せ! 予定工期の半分で 遅延が発覚 2008/09/20 予定工期の半分で 遅延が発覚 トータル 8km、 1時間で 3km だった ⇒ (4km(見積り) - 3km(実績)) ÷ 4km = 25% (遅れ) 残り 1時間で 5km だから、後半のスピードを… ⇒ 5km/h(目標) ÷ 4km/h(見積り) = 125% … 25% アップすればよい (?)‏ これは実績ベースで考えないといけない ! ⇒ 5km/h ÷ 3km/h(実績) = 167% !!

ソフトウェアのサイズ (1)‏ コード行数 同一言語、同一ライブラリ 同一の品質 一定の条件を満たせば、サイズを測るのに使える。 2008/09/20 コード行数 一定の条件を満たせば、サイズを測るのに使える。 同一言語、同一ライブラリ 同一の品質 コード品質計測ツール リファクタリングに主眼を置いたコードインスペク ションの実施

ソフトウェアのサイズ(2)‏ 画面数と帳票数 日本の業務アプリでは、けっこう使える ※ ( 人月 = 画面数 x 1.55 )‏ 2008/09/20 画面数と帳票数 日本の業務アプリでは、けっこう使える ※ ( 人月 = 画面数 x 1.55 )‏

ソフトウェアのサイズ (3)‏ ファンクションポイント (FP)‏ 現在、世界的に一番権威がある 2008/09/20 ファンクションポイント (FP)‏ 現在、世界的に一番権威がある FP算出法にも何通りかあるので、どの手法で計測 したか明らかにすること NESMA, NESMA簡易法, 画面要素法 (日本)‏

ソフトウェアのサイズ (4)‏ その他 計測手法の選定には オブジェクトポイント法、ユースケースポイント法 など 2008/09/20 その他 オブジェクトポイント法、ユースケースポイント法 など 粒度を一定にするのが難しそう 計測手法の選定には 安定して計測できること 他と (時間軸, 空間軸) 比較可能なこと

成果物の見積り 2008/09/20 生産性を、個々の成果物 (work) の量に対し て計測/見積りしている場合は、ソフトウェア のサイズから成果物の量を見積もる 設計書のページ数 コードの行数 テスト報告書のページ数 マニュアルのページ数

生産性 (1)‏ ※ 生産性を見積もる ← 生産性を計測すること 作業を、少なくとも 3つに分けて計測する 2008/09/20 ※ 生産性を見積もる ← 生産性を計測すること 作業を、少なくとも 3つに分けて計測する 要件開発 (なにを作るか) … いわゆる要件定義から 外部設計まで コンストラクション (どう作るか) … いわゆる内部 設計から実装完了まで 検証 (どこか間違っていないか) … いわゆる結合テ スト以降

生産性 (2)‏ 2008/09/20 細かく見る場合には、前述の成果物 (work) 単位にまで分けて計測することも。 ※ 米国産の見積り支援ソフトには、そこまで入っている。 中間成果物まで細かく規定されている「重たい」開発プロセ スなら、可能。

FP - 成果物量 - 生産性 の例 2008/09/20 (米国のデータ例 )‏

生産性データの適用範囲 ソフトウェア開発の生産性はバラつきが大きい 条件が変わったら、適用できない ! 人 (属人的なスキル)‏ 2008/09/20 ソフトウェア開発の生産性はバラつきが大きい 人 (属人的なスキル)‏ チーム (属人的、組織的なスキル)‏ 開発プロセス ※ 求められる品質と生産性の関係は、おそらく定量化可能 条件が変わったら、適用できない ! 推定 + 不確実性を大きく見る必要がある

閑話休題 (2) : テストの工数 「テスト工程」の工数はバラつく テストケース開発 ~ テスト実施 ← サイズに比例 2008/09/20 「テスト工程」の工数はバラつく テストケース開発 ~ テスト実施 ← サイズに比例 バグ票の起票 ~ トリアージ ~ 不具合修正 ~ 再テ スト ← バグ数に比例 起票以降の工数は、バグを作りこんだ工程 (設計/ 製造) に振替えるべきかも。 ※ そうすれば、設計/製造での品質向上へのインセ ンティブになる。

不確実性は非対称 ~ β分布 2008/09/20 短縮は限度があるけど、遅延はどこまでも 確率分布が最大の点より、期待値は右側

3点見積り ~ β分布の近似 2008/09/20 最良と最悪も加えた 3点から算出する

閑話休題 (3) : レビューの工数 文書のバグ出しレビュー = インスペクション 2008/09/20 文書のバグ出しレビュー = インスペクション レビュアーによる査読 : 0.x~0.xH/ページ ×3人 レビューミーティング : 0.x~0.xH/ページ ×5人 文書修正 : 0.x~0.xH/ページ ×1人 レポート・フォロー・進行 : 0.x~0.xH/ページ x1人 合計 : 0.x~0.x人・H/ページ

プロジェクトとの関わり 2008/09/20

まとめ (1) : 計測なくして 見積りなし 精確な計測から、精確な見積りが生まれる 精確な見積りができると… 2008/09/20 精確な計測から、精確な見積りが生まれる 精確な見積りができると… 赤字プロジェクト・デスマーチが減らせる 生産性の向上が計れるようになる ※ 見積り精度が±10%で、実績が20%良かったら 、 10%位は生産性が上がったと言える。 ⇒ 開発プロセスの改善が進む

まとめ (2) : 工数見積りは技術 サイズ・工数を見積もるところまでは、技術 過去の計測値から未来を予測する 見積りは確率 2008/09/20 サイズ・工数を見積もるところまでは、技術 「政治」嫌いの開発者も知ってほしい 過去の計測値から未来を予測する 計測していなければ、良い見積りは出せない 見積りは確率 未来予測に 100% 正確はありえない 幅のある未来予測から決断するのは経営責任

参考書 2008/09/20