ファイル TEF東海メトリクス勉強会 Summary10 nao

(1)

TEF 東海メトリクス勉強会　第 10 回

(2)

 方向を変えなければ、いま向かっているところにしかたどり着けない　－老子

 まだ着かないの？　－こどもが、ドライブのとき親に必ず聞く言葉

 進み具合はどう？　－ソフトウェア管理者が

、開発者とテスト担当者に必ず聞く言葉

(3)

 _{プロジェクトの目的}

 目的に対して現在位置を正確に知る

 進捗状況を効果的に追跡

 _軌道修正

 効果的な要求管理ができる

(4)

 創造的作業・調査作業がつきもの

 進捗管理を効果的に行うことが重要

進捗を測定するメカニズムとメトリクスを紹介する

紹介するメトリクスはインプロセスメトリクスと呼ばれる

(5)

1. プロジェクトのマイルストーン

2. _{コード結合} 3. _{テストの進捗}

4. _{欠陥の発見と修正} 5. _{プロセスの有効性}

(6)

ソフトウェアを出荷するという目標目標を達成するために

プロジェクト計画を明確に定義

(7)

 _{詳細化すべき}

 進捗評価が促されるくらい

(8)

 _{最も良い方法は}

 マイルストーンを測定可能にしておくこと

 ２週間間隔で定義するのが一般的

 ただし、マイルストーンに何を選ぶかは

 さまざまな要因に依存する

(9)

 _{開発方法論}

 プロジェクトマネジメント方法論

 プロジェクトのリスクレベル

 _{チームの経験と成熟度}

 管理チームの快適さレベルと管理スタイル要因を考慮したうえで、最良な方法は

(10)

 _Specific _{（明確性）}

 _Measurable _{（測定可能性）}

 _Achievable _{（達成可能性）}

 _Relevant _{（関連性）}

 _{Time based} _{（時間性）}

(11)

ウォーターフォール型開発モデルに従ってプロジェクトを進める…

(12)

 _要求定義

 _{アーキテクチャ設計}

 _詳細設計

 _{コーディング}

 _結合

 _テスト

 _{カットオーバー}

(13)

 _{要求定義　・・・}

マイルストーン期限

レビュー可能な要求仕様草稿の作成２００６年６月１日開発メンバーとテストメンバーによる内部要求レビュー２００６年６月８日要求仕様の改定と顧客への提出（顧客の同意確認のため）２００６年６月１５日

顧客承認の獲得２００６年６月２５日

要求仕様の最終版作成、公式な変更管理アイテムとして登録２００６年６月３０日

(14)

 _Specific _{（明確性）：}

それぞれのマイルストーンの責任者を決めるとよい

(15)

 _Specific _{（明確性）：}

(16)

 _Measurable _{（測定可能性）：}

測定可能な関連イベントがある

「要求仕様の草稿は完成したか？」

イベントを測定すれば、達成度を把握できる

「レビュー会議は開催されたか？」など

(17)

(18)

マイルストーンの設置間隔過去の類似プロジェクト

リソース配分とプロジェクトニーズ同じ顧客の過去プロジェクト

(19)

きちんと考慮しているなら．．．

達成可能性は高いと考えてよいだろう

(20)

(21)

 _Relevant _{（関連性）：}

どのようなシステムを構築するのか

内部チームと顧客の両者が合意しているのか

これを確認することは・・・・・・・・・

(22)

製品の出荷を成功裏に収め最終的に顧客満足を得るのに

極めて重要

(23)

(24)

 _{Time based} _{（時間性）：}

それぞれのマイルストーンには期限が設けてあるので

時間性を満たしている

(25)

 _{Time based} _{（時間性）：}

(26)

 開発工程が長くなればなるほど・・・

その中間にマイルストーンを設置したい長期間にわたる

作業の進捗状況を見えないまま

放置しておきたくないと思うのは・・・ごく常識的なこと

(27)

 _{ググってみました}

プロジェクト管理ツール MS Project

MS Project _Redmine^Redmine

開発マイルストーン開発マイルストーン

ガントチャート forExcel ガントチャート

forExcel

OpenPro j

TaskLine TaskLine GanttPrje

ct

GanttPrje ct

Tra c Tra

c

TracGant t

dotProje ct dotProje

ct ProjectKeepe

r

ProjectKeepe r

]project- open[ ]project-

open[

Retrospectiv a

Tugboat GTD Tugboat レビュアブルマインド GTD

レビュアブルマインド Tam

a Tam

a JIRAJIRA

ナレジオンナレジオン

Basecam p

Project.n et Project.n

et

eGroupWa re

SugarCR M SugarCR

M Gantte

r Gantte

r

Backlo g Backlo

g SI Object

Browser PM SI Object

Browser PM ProjectPier

ProjectPier

activeColl ab activeColl

ab TUTOS TUTOS

Zoho Project

Zoho Project TimeTracker

FX

TimeTracker FX

(28)

 いろいろなビューを用いて可視化する

WBSWBS

マイルストーンマイルストーン

工数管理工数管理

PERT 図 PERT 図ドキュメント管理ドキュメント管理コスト管理

コスト管理

イナズマ線イナズマ線

進捗管理進捗管理タスク管理

タスク管理

課題管理課題管理

ガントチャートガントチャート

(29)

「ゲート」として利用できる次のステップへと進むために

達成しなければならない基準が設けられた

プロジェクトの完了と成功を決定づけるソフトウェアプロジェクトの

プロジェクトの区切りである

重要な要因である

(30)

 ゲートの基準を満たせないと・・・

 ゲートの基準を満たしていないのに、

後に続くアクティビティを開始してしまうとリソースの再割り当てを行うことになったり

コストのかかる手戻しに結びつきかねない

(31)

 上級マネージャがレビューし、承認したビジネスケース：プロジェクトを開始する前に、このプロジェクトに資金を投入してよいか判断する必要がある。

 開発チームがレビューし、承認したソフトウェア設計：コードを作成し始める前に、ソフトウェア全体を知っておきたい。

 重要度の高いすべてのコードに対するコードレビューの完了：レビューにより、できるだけ多くの欠陥を発見し、修正を終えておくことが望ましい。レビューは、費用がかかる正式なテストを実施する前に実施する

。

 正式テスト計画の完全な実施と、目標とした成功レベルの達成：ソフトウェアが顧客の要望や契約上の期待に合致していることを、出荷前に確認する必要がある。

(32)

 _{実際にコードを作成}

 _{単体テストを実施}

 正式なシステムテストのために結合する作業

 これらの作業を含んだソフトウェアライフサイクル工程のひとつ

 何度も実施する一連の作業

(33)

 新たな欠陥を作りこんでしまうことがある

 新規に作成したコードと

 すでに結合を終えたコード両方に

 修正するには新しいコードを作成・結合この基本的な活動

決定的に重要

進捗状況を信頼できる方法で可視化が必要

(34)

 _{成熟度の低い組織では}

 「完了率」を使っているかも

 定義・計算次第では誤解を招く恐れ

 開発者の主観によって決められたりすると

 異なる結果が容易に得られる間違った認識

「 M 」が欠落、 SMART の基準を満たしてい ない

(35)

 _{そうでなく・・・}

 作業工数の工数を見積もり

 値の比較結果に基づいて完了率が測定

 「完了したマイルストーン比率」を測定

 異なる結果が容易に得られる

コード結合の目標と密接に

「関連している」わけではない

(36)

 どれだけ多くの工数を費やしたか

 _{予算の観点から把握}

 コード量・コーディング進捗率

コード量・コーディング進捗率

作業工数から何も知ることができない

(37)

 _{筆者が選ぶメトリクス}

 結合作業に引き渡したコード行数（ KLOC)

 別名、コード結合メトリクス

 結合ライブラリへチェックインした行数変更するには

正式な変更要求が必要

(38)

 _{許容可能な値の程度}

 長期間わたって調査しておく必要がある

 _{許容可能な値を}

 「期待されるコード結合パターン」

 _{と呼ぶことにする}

(39)

(40)

注目すべきは

結合時期が早いほど

プロジェクトのリスクが低減する適切にテストするために多くの時間を

確保できる

(41)

1. プロジェクトの特性に最も適した成功コード結合パターンを選ぶ

2. 選択したパターンに基づいてコード結合計画を作成する

3. コーディング工程におけるコード結合の進捗実績を追跡し、計画と比較する。

4. 実績が計画から乖離したときには、適切な対策を実施する

(42)

コーディング工程におけるコード結合というマイルストーン

SMART の「 M 」にすることができる

(43)

 _{正式テスト}

 観測や測定が最も容易に行える段階のひとつ

 _{テストの進捗の評価}

 テスト計画に基づいて行う

 テスト計画には、テスト工程で

 どのようなテストを実行するのか明記

(44)

 _{テスト工程}

 何件のテストケースを実行

 何件のテストケースがパスしたのか

 _{明確に観測できる}

1.ある時点で実行したテストケース数

2.ある時点で成功したテストケース数

(45)

 許容可能な値の管理限界

 実績値がこの範囲の外側に出てしまった場合何らかの対策が必要

(46)

SMART の「 M] を満たしたテストマイルス トーンを設定できる

(47)

 第 7 章で述べたとおり

 欠陥は最も基本的で、かつ観測可能なもの

 発見と修正を測定すると

 品質とスケジュールの両方の進捗を測定可能

 パワフルなインプロセスメトリクス

(48)

 第 7 章で欠陥パターンを予測する方法

 _{テストの進捗と同じく}

 実績値が予測値の管理限界の外側に出た場合

 _{対策が必要}

 発見の実績値の曲線のピークが

 予測パターンより早く・低い

⇒良いニュースかも　⇔　逆も然り

(49)

 テキスト図 10.5 と 10.6 の例

 計画は過去の履歴の平均値に基づいている

 標準偏差に基づいた管理限界を与える

 欠陥発見計画を立案すれば

 計画に対する実績の追跡と

 計画から大幅に乖離した部分の調査も可能

(50)

 テキスト図 10.7 の例

 発見、修正済み、修正未了欠陥数

 新しい欠陥が発見されるよりも早く

 欠陥の修正を完了すべき

（欠陥バックログを減らす）

 コードの品質を出荷可能状態へ近づける

(51)

 欠陥除去率：欠陥発見パターンの実績から、９０％を達成していること

 深刻な影響をもたらす欠陥がバックログに残っていないこと

(52)

 バックオフィスの業務自動化システムに対してセーフティークリティカルなシステムの基準はずっと厳しい

 欠陥発見曲線の実績値を 1 日に割り当てた要因による欠陥除去数結びつけて評価してもよく、出荷可能な品質レベルにいつ到達するか予測できるようになる

(53)

 欠陥発見の実績値に対して

 開発エンジンの欠陥修正能力を考える欠陥バックログが時間経過とともにどのように減っていくかを予測できる

(54)

 初期の計画とインプロセス

 比較対象となる類似プロジェクトの選択

開発プロセスをどのくらい効果的に実施できるか潜在的な期待

選択したメトリクスの目標値などに反映

(55)

 前もって予測できないものの・・・

 ばらつきが間違いなくある

他のメトリクス関連させて使えるようなプロセス有効性メトリクス

導入することには意義がある

(56)

 インスペクション有効性メトリクス

 _定義

インスペクション時間　 ÷　インスペクション対象成果物の規模

インスペクション時間：インスペクションに費やした総工数 ( 人時 ) インスペクション対象成果物の規模：コードであれば KLOC

要求と設計であれば FP

(57)

 プロジェクトが「計画どおりに」

 進んでいるか判断するために

 欠陥発見メトリクスと関連付けて

 _{使うことができる}

(58)

 _{シナリオ１：}

 欠陥発見率は計画より低い

 コードインスペクション有効性は目標どおり

 または、目標を上回っている

「プロジェクトは安定して進んでいるようだ

。予想よりよさそう。現段階で対策必要なし」

(59)

 _{シナリオ２：}

 欠陥発見率は計画より低い

 コードインスペクション有効性も目標下回る

「欠陥の見逃しがあったに違いない

インスペクションを再び実施するか、または、。これ以降の工程での欠陥除去数を増強する

それにはリソースの見直しが必要である

(60)

 _{シナリオ３：}

 欠陥発見率は計画より多い

 コードインスペクション有効性は目標どおり

 または、目標を上回っている

「有効なインスペクションが実施できたので早い段階で欠陥を見つけられたのだろう

コードの品質大丈夫。継続的状況把握必要。」。

(61)

 _{シナリオ４：}

 欠陥発見率は計画より多い

 コードインスペクション有効性は目標下回る

「注意！コード品質はどうも怪しい。品質確保のための改善措置を直ちに実施。

スケジュール、予算の見直し必要。」

(62)

 ソフトウェアプロジェクト

 元来、リスクがつきもの

 成功を収めるためには、

 プロジェクトの進捗を正確に評価できることが徹底的に重要

(63)

1. 開発ライフサイクル全体をカバーする SMART なマイルストーンを定義しなさい

2. コード結合メトリクスと、対象とするコード結合パターンを定めなさい

3. テストのメトリクスを定め、その目標値を設定しなさい

4. 欠陥発見および欠陥修正のパターンを定め、欠陥バックログを監視しなさい

5. 開発ライフサイクルのすべての主要工程に対して

、プロセス有効性メトリクスとその目標値を設定しなさい。