Microsoft PowerPoint - processmetrics2-.ppt

Size: px

Start display at page:

Download "Microsoft PowerPoint - processmetrics2-.ppt"

けいしょうほがり
5 years ago
Views:

1 ソフトウェア工学 III プロセスデータ資源データとプロジェクト管理ソフトウェア工学講座門田暁人 B303 室, 内線 5311

2 ソフトウェア開発に関するデータプロジェクト特性データプロジェクト種別, 利用局面, システム特性, ユーザ要求管理, 要員スキル, システム規模, 工数, 品質など将来の開発の工数予測や計画立案などに役立つ. プロダクトデータ提案依頼書, 要求仕様書, 概要設計書, 詳細設計書, ソースコード, テストケースなど現在の開発保守や次期バージョン開発に役立つ. プロセスデータ, 資源データガントチャート ( 作業計画実績管理表 ),WBS( 作業分解図 ), 設計レビュー報告書, 障害管理票, 開発者の能力, プロダクトデータを時系列に並べたものプロジェクト管理 ( マネージメント ) に役立つ.

3 本講義の目的プロセスデータ, 資源データにはどのようなものがあり, プロジェクト管理にどう役立てられるかを学ぶ. データの例 WBS PERT ガントチャート設計書, ソースコードの履歴テスト管理表...

4 プロジェクト管理とはプロジェクトの現状を把握する. PCDA(Plan Do Check Action) サイクルをまわす. 計画, 実施, 確認, アクションプロジェクト関係者間の調整を行う. 要求, 利害, 意見, 対話, 報告, 連絡変更の管理仕様変更, メンバー変更, スケジュール変更マイルストーンの管理設計の終了日, コーディングの終了日,...

5 プロジェクト管理の 3 大技術 (1)WBS WBS(Work Breakdown Structure) プロジェクト全体を詳細な作業に分割する手法例 - 作業 = 成果物がある. 作成すべき成果物 ( 要求仕様書, 設計書, ソースコード, レビュー報告書など ) を, より詳細な成果物に分割する. 木構造設計項目定義作成データ作成機能 A 機能 B 機能 C 基本データ処理例外データ処理統合データ処理資料作成承認

6 プロジェクト管理の 3 大技術 (2)PERT PERT(Program Evaluation and Review Technique) WBS で洗い出された作業を組み合わせ, プロジェクトを最短で終了させるための計画を立案する手法ネットワークロジック + 見積もり値 + クリティカルパス例出典 : IPA-SEC 編, 組み込みソフトウェア開発におけるプロジェクトマネジメント導入の進め, SEC BOOKS

7 プロジェクト管理の 3 大技術 (3) ガントチャート Gantt chart( ガント図, 工程管理図, 線表 ) WBS+PERT+ リソース ( 人間 ) 作業, 人, スケジュールを横型棒グラフで示したもの各作業はいつ始まり, いつ終わるのか誰が各作業を担当するのか出典 : IPA-SEC 編, 組み込みソフトウェア開発におけるプロジェクトマネジメント導入の進め, SEC BOOKS

8 ガントチャートの例 2 種類のガントチャートタスクガントチャートリソースガントチャート (MS Project を用いた例 )

9 ガントチャートの計画と実績計画の例

10 ガントチャートの計画と実績実績の例

11 テスト管理表ガントチャートに準じるガントチャート + テストケース数 + 障害情報

12 障害管理表 (1 障害あたりの記録 ) 障害番号対応状況起票分類起票日起票者責任者問題概要発見日テスト対象発見箇所発見工程発見作業発見バージョン問題処理機能問題内容再現度再現方法重要度優先度問題原因混入工程混入対象バージョン本来発見すべき工程発見できなかった要因修正工程修正対象バージョン修正工数 ( 人時 ) 修正内容確認方法最終変更日完了日

13 障害の推移発生障害数件数障害の平均未解決時間未解決障害数時間

14 パレート図 ( 累積度数分布図 ) 障害の各種類について, 数の多い順に棒グラフと累積百分率を示したもの出典 : 浅瀬野, QC7 つ道具と新 QC7 つ道具,

15 設計書の推移

16 ソースコード行数の推移

17 事例事例 1: 開発作業履歴を用いたマイクロプロセス分析障害管理ツール (GNATS), 構成管理ツール (CVS) の履歴事例 2:GQM(Goal-Question-Metric) モデルに基づくプロジェクトのモニタリング

18 事例 1: マイクロプロセス分析目的ソフトウェアプロダクトの品質を評価するのと同様に, ソフトウェアプロセスの品質を評価したい. アプローチ作業記録からプロセスに関する詳細な ( ミクロな ) 情報 ( 作業の順序, 時間, 作業量 ) を得る. 作業手順を定めるプロセスモデルを定義する. プロセスモデル通りの作業が行われているかどうかを評価する.

19 作業記録の例障害管理ツールの操作履歴障害発生時刻, 障害修正時刻,... 構成管理ツールの操作履歴ソースコードのチェックイン, チェックアウト

20 ソフトウェアプロセスモデルソフトウェア開発における作業間の順序関係や包含関係を記述したもの例該当箇所の修正バグ修正該当箇所の修正確認テスト修正箇所以外の回帰テストアクティビティ図 (UML) などを用いて表現できる.

21 実験目的 : 商用プロジェクトのプロセスの品質を評価する. プロセスモデルに準拠した作業が行われているか. 対象プロジェクトプローブ情報システム開発マルチベンダによるウォータフォール型中規模開発分析の対象工程 : コーディング工程後半 ~ 組織内結合試験工程作業記録 :CVS と GNATS( 障害管理ツール ) CVS 記録 :518 レコード, バグ数 :31 件

22 対象プロセスモデル開発メンバにお願いした手順想定プロセスモデル ( アクティビティ図 ) 障害発見 1 発見日時確認 2GNATS 登録ソースコード修正修正確認テスト 3CVS に修正ソースコード登録 4GNATS ステータス完了に変更障害修正完了 GNATS 障害発見 GNATS 登録 GNATSステータス完了に変更障害修正完了ソースコードチェックアウトソースコード修正修正確認テスト CVS CVS に修正ソースコード登録

23 結果 : 作業履歴障害番号発見日時確認 2GNATS 登録 3CVS に修正コード登録 4 ステータス完了に変更 8/1 8/3 8/5 8/7 8/9 8/11 8/13 8/15 8/17 8/19 8/21 時刻

24 結果 : 作業履歴障害番号一括登録手順 3,4 の入替り手順 3 の漏れ 1 発見日時確認 2GNATS 登録 3CVS に修正コード登録 4 ステータス完了に変更 8/1 8/3 8/5 8/7 8/9 8/11 8/13 8/15 8/17 8/19 8/21 時刻

25 結果 : 手順漏れ, 不遵守, 登録情報漏れ一覧項目手順漏れ (2) 手順漏れ (3) 手順漏れ (4) 手順の不遵守 (1 2) 手順の不遵守 (2 3) 手順の不遵守 (3 4) 登録情報漏れ, 誤り (2) 登録情報漏れ, 誤り (3) 該当件数割合 0% 6.5% 9.7% 22.6% 0% 22.6% 22.6% 0% 1 発見日時確認,2GNATS 登録, 3 構成管理ツールに修正ソースコード登録 4GNATS ステータス完了に変更

26 まとめプロセスの品質を評価するためのマイクロプロセス分析を行った. 障害修正のプロセスが定義された商用開発プロジェクトのデータに適用した. 5 個の手順漏れ 14 個の手順の不遵守 7 個の登録情報漏れ誤りを発見することができた.

27 事例 2:GQM モデルに基づくプロジェクトのモニタリング GQM パラダイム : ゴール指向の分析アプローチ 1984 年に Basili と Weiss によって提唱された. 目的を明確化し, 収集データやメトリクスと対応付ける. Goal プロジェクトを日々モニタリングすることで, 問題の兆候をできる限り早期に検出する. Question Metric バグ密度, ファイル変更密度など [1] V.R. Basili and D.M. Weiss, A methodology for collecting valid software engineering data, IEEE Trans. on Software Engineering, Vol.SE-10, No.6, pp , 1984.

28 GQM に基づくプロジェクトモニタリングの概要ソフトウェア開発管理者へのアンケート開発時の問題点解決すべき課題構成管理 CVS メール Mailman 障害管理 GNATS Goal Question Metric 1 日ごとのプロジェクトサマリソースコード総行数総ファイル数変更者が N 人以上のファイル数 M 行以上修正されたファイル数障害発生数 ( 種類毎, 累積 ) 対処済み障害数障害滞留時間... GQM モデルによるデータの解釈

29 収集データと得られる情報構成管理ツール (CVS) 行の追加開発が進んでいる or 停滞している. 1 人日あたりの行数は? クローンは? 行の削除仕様変更, バグなど. 規模が大きいものは要注意ファイル変更者何人が同一ファイルを触っているか. 急に増えると要注意. 同時変更ファイルファイル間の関連の把握など障害管理ツール (GNATS) 上流工程 ( 設計書レビュー ) から下流 ( テスト ) まで対応状況累積障害, 残存障害, 障害密度,... 混入工程仕様バグ, 設計バグ, コーディングバグ原因ロジック, インタフェース,... 障害箇所どのバージョンのモジュールか修正工数人時など

30 アンケート結果 : プロジェクト遅延の発生プロジェクトの大きな遅延を経験したことはありますか? はい :18 人いいえ :1 人無回答 :1 人 ( 計 20 名 ) 遅延が発生した工程を列挙してください.( 複数回答 ) 要求分析概要設計詳細設計コーティンク単体テスト結合テストシステムテスト n.s.

31 遅れが生じた主な原因上流工程の設計品質が悪い. 単体テスト結合テスト段階のプロジェクト管理不良. 要求仕様の矛盾. 期待した性能が出ないライブラリパッケージソフトウェアの品質の問題. 要求が大幅に膨れ上がった. 仕様変更の発生. 設計途中で見積り精度の悪さが発覚. システムテストで致命的な設計不備が見つかった. 要件が確定しない. 本来単体テストで出るべきバグが後工程で出現. 詳細設計フェーズで規模見積り過少が判明. 結合テスト工程で単体テストの不備が判明.

32 遅れが生じた主な原因現物あるいは設計書を ( 顧客に ) 見せると変更要求が多発する. 顧客との関係. 技術不足. マネジメント ( 金人 ) 不足結合テスト時にインタフェースの不整合が発生した. 仕様の理解不足. 要求仕様の顧客との合意もれ. 詳細仕様のあいまいさによるブレークダウン不能. 仕様変更の頻発新規プロジェクトのため, 業務知識の欠如. 新技術の導入による開発ノウハウの欠如.

33 プロジェクト遅延の兆候プロジェクト遅延が発覚する前に, 何らかの兆候はありましたか? はい :17 人いいえ :3 人無回答 :1 人考慮もれのチェックレビュー等がなかったライブラリパッケージソフトの検証が十分でない完成が少しずつ遅れだす完了との進捗報告に具体的な根拠がない単体テストの進捗遅れ仕様変更が多発. 節目での見積り規模の増加工数の増大不具合の増大

34 プロジェクト遅延の兆候命令系統のみだれ設計仕様書の頁数が少ない不安定な仕様. 別企業の開発チームとの調整の難航仕様の確認の打ち合わせが少なく不安だったが納期が短く進めるしか選択がなかった. 不具合の解決が進まない. 成果物の品質が悪い. 打合せの工数は大きいが成果物ができていないシステムテストでバグが想定以上に発生していた兆候はあったがマネジメントされていなかったため何をどうしたらよいかわからない状態だった

35 プロジェクト進捗管理における課題プロジェクト進捗管理における課題をお持ちでしたらご回答ください.( 複数回答 ) 13 不安定な要求仕様設計不誠実な報告書 ( 悪い報告が入ってこない ) ソフトウェアの品質が悪く, テスト項目を消化できない. マイルストーン設定が困難その他無回等

36 GQM モデリングの材料 Goal プロジェクトの問題 : 不安定な要求不完全な設計劣悪なソースコード品質など目的 : プロジェクトの現状理解, 問題の検出プロジェクト管理者の立場 Question? Metric 構成管理システム (CVS): 変更したファイル, 変更者, 日時, 追加行数, 削除行数などメール管理システム (Mailman): 送信者, 宛先, 表題, リファレンス, 本文など障害管理システム (GNATS): 対象ファイル, 報告者, 日時, 種別, 状態 ( 未解決 / 解決済 ), 優先順位 ( 高 / 中 / 低 ), 重要度 ( 高 / 低 ) など

37 GQM モデルにおける Goal プロジェクトをモニタリングすることで, 問題の兆候をできる限り早期に検出する. 要求が不安定設計が不完全リソース配置が不適切コーディング品質が悪いこれら 4 つの問題の兆候を検出するための GQM モデルをそれぞれ作成した.

38 Model 1 要求の不安定さの評価 (1/2) Goal 構成管理データ (CVS) と障害管理データ (GNATS) からプログラム変更, 仕様変更パターンを解析し, 企業における特定のプロジェクトにおいて, プロジェクトマネージャの視点から, 要求の不安定さについて評価する Question プログラム変更頻度は? プログラム変更規模は? プログラム変更範囲は? 仕様変更数の増加傾向は? Hypothesis ( 仮説 ) 要求仕様が不安定ならばプログラム変更が頻繁に起きる. 要求仕様が不安定ならば規模の大きな変更が発生する. 要求仕様が不安定ならば範囲の広い ( 多数のファイルにまたがる ) 変更が発生する. 要求仕様が不安定ならば仕様変更数が著しく増大する.

39 Model 1 要求の不安定さの評価 (2/2) Goal 構成管理データ (CVS) と障害管理データ (GNATS) からプログラム変更, 仕様変更パターンを解析し, 企業における特定のプロジェクトにおいて, プロジェクトマネージャの視点から, 要求の不安定さについて評価する Question プログラム変更頻度は? プログラム変更規模は? プログラム変更範囲は? 仕様変更数の増加傾向は? Metric A: ファイルの更新回数 ( 累積 ) B A B: ( 一定規模以上の ) 行削除回数 ( 累積 ) C: 追加行数 ( 累積 ) D C E: ファイル数 G: プログラム行数 (KSLOC) H: 仕様変更数 D: 削除行数 ( 累積 ) ( 累積 ) F: ( 一定規模以上 ) 行削除のあったファイル数 F E H G

40 Model 2 設計の不完全さの評価 (1/2) Goal 構成管理データ (CVS) と障害管理データ (GNATS) からプログラム変更, 仕様変更パターンを解析し, 企業における特定のプロジェクトにおいて, プロジェクトマネージャの視点から, 設計の不完全さについて評価する Question Hypothesis ( 仮説 ) ファイル変更者数は? プログラム変更頻度は? プログラム変更規模は? プログラム変更範囲は? 設計バグ数の増加傾向は? 設計が不完全ならば 1 つのファイルを多人数が変更する. 設計が不完全ならばプログラム変更頻度, 規模, 範囲が大きい. 要求仕様が不安定ならば設計バグの発見数が増大する.

41 Model 2 設計の不完全さの評価 (2/2) Goal 構成管理データ (CVS) と障害管理データ (GNATS) からプログラム変更, 仕様変更パターンを解析し, 企業における特定のプロジェクトにおいて, プロジェクトマネージャの視点から, 設計の不完全さについて評価する Question Metric ファイル変更者数は? I: 2 人以上に変更されたファイルの割合プログラム変更頻度は? J: 1 ファイルあたりのファイル変更者数 ( 平均 ) プログラム変更規模は? プログラム変更範囲は? (Model 1 参照 ) K: プログラム行数 (KSLOC) 設計バグ数の増加傾向は? L K L: 設計バグ発見数 ( 累積 )

42 Model 3 リソース配置の評価 (1/2) Goal 構成管理データ (CVS) と障害管理データ (GNATS) からプログラム変更, 障害発生 / 修正パターンを解析し, 企業における特定のプロジェクトにおいて, プロジェクトマネージャの視点から,Resource Planning について評価する Question Hypothesis ( 仮説 ) ファイル変更者数は? 発生障害数と未対応障害数の関係は? 対応優先度の高い障害の滞留時間は? プログラミングにおけるリソース配置に問題があるならば,1 つのファイルを多人数が変更する. 障害への対応のためのリソースが不足しているならば,( 発生障害数が急増していない場合であっても ) 未対応障害数が減らない. 障害への対応のためのリソースが不足しているならば, 障害の滞留時間 ( 障害が報告されてから対応済みとなるまでに要する時間 ) が減らない.

43 Model 3 リソース配置の評価 (2/2) Goal 構成管理データ (CVS) と障害管理データ (GNATS) からプログラム変更, 障害発生 / 修正パターンを解析し, 企業における特定のプロジェクトにおいて, プロジェクトマネージャの視点から,Resource Planning について評価する Question ファイル変更者数は? 発生障害数と未対応障害数の関係は? 対応優先度の高い障害の滞留時間は? Metric (Model 2 参照 ) N: 優先度中以上の未対応障害数 ( 累積 ) M: 優先度中以上の障害の発生数 ( 累積 ) O: 優先度中以上の障害の滞留時間 ( 平均 )

44 分析例 1

45 分析例 2

46 分析例 3

47 分析例 4

48 分析例 5

49 まとめ GQM モデルによるプロジェクトモニタリング事例の紹介事例 1: 不安定な仕様事例 2: 頻繁なソースコード変更事例 3: 人手不足事例 4: 要追加テスト事例 5: 開発要員の変更

50 本講義のまとめプロジェクト管理に役立つプロセスデータ資源データ WBS 作業の分解 PERT 作業間の関係, 作業量ガントチャート WBS + PERT + スケジュール + 人間テスト管理表ガントチャート + テスト障害情報設計書, ソースコード, 障害の履歴プロジェクト状況把握 2 つの事例事例 1: 作業履歴を用いたマイクロプロセス分析事例 2:GQM モデルに基づくプロジェクトのモニタリング

51 次回 1 月 19 日 ( 金 )2 限ーレポート提出 & 発表レポート課題コードクローン分析 or プロダクトデータ分析希望者はレポート課題の内容を発表することレポートの内容について説明する. レポート用紙をスクリーンに映す, もしくは, パワーポイント等のプレゼン資料を用いる. 時間が余れば, 提出されたレポートの中からいくつかを講義中に ( 門田が ) 紹介します. 連絡先門田暁人 akito-m@is.naist.jp B303 室, 内線 5311

はじめに本ドキュメントは Redmine を使用して稼働する定量的プロジェクト管理ツール ( 以下 IPF と略します ) のヘルプです IPF の操作に関わる機能を解説しており Redmine 及び構成管理ツール (Subversion Git) の標準機能については本ヘルプの記載対象外として

はじめに本ドキュメントは Redmine を使用して稼働する定量的プロジェクト管理ツール ( 以下 IPF と略します ) のヘルプです IPF の操作に関わる機能を解説しており Redmine 及び構成管理ツール (Subversion Git) の標準機能については本ヘルプの記載対象外として D08-3 定量的プロジェクト管理ツール Redmine 版ヘルプ操作編第 1.0 版 2012 年 2 月 28 日独立行政法人情報処理推進機構技術本部ソフトウェアエンジニアリングセンター Copyright 2012 IPA, Japan. All rights reserved 1/29 はじめに本ドキュメントは Redmine を使用して稼働する定量的プロジェクト管理ツール