1 / 54

Disciplined Software Engineering Lecture #8

Disciplined Software Engineering Lecture #8. Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Sponsored by the U.S. Department of Defense. 講義の概要. 品質とは何か? 製品とプロセスの品質 品質の経済学 品質戦略 プロセスの特徴づけ プロセスのベンチマーキング 欠陥摘出の管理 欠陥除去 欠陥予防. ソフト品質とは何か?. 基本的定義

Download Presentation

Disciplined Software Engineering Lecture #8

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Disciplined Software Engineering Lecture #8 • Software Engineering Institute • Carnegie Mellon University • Pittsburgh, PA 15213 • Sponsored by the U.S. Department of Defense

  2. 講義の概要 • 品質とは何か? • 製品とプロセスの品質 • 品質の経済学 • 品質戦略 • プロセスの特徴づけ • プロセスのベンチマーキング • 欠陥摘出の管理 • 欠陥除去 • 欠陥予防

  3. ソフト品質とは何か? • 基本的定義 • ユーザのニーズを満たすこと • ニーズであり、ウォンツではない • 真の機能的なニーズはしばしば知り得ないものである • ニーズの階層 • 要求されたタスクを行う • 性能要求を満足させる • 利用しやすく便利であること • 経済的でタイムリーなこと • 頼りになり信頼できること

  4. 頼りになり信頼できこと • 使われるためにソフトウェアは以下でなければならない • 速く容易にインストールできる • 矛盾無く稼働する • 正常ケース、異常ケースを適切に扱う • 破壊的なことや予期しないことは行わない • 本質的にはバグがない • 潜在バグは以下でなければならない • 運用上の影響が小さい • 破壊的でない • 顕在化するのは稀である

  5. 品質の良いプロセス • 品質のよい製品を作る • プロセスのユーザのニーズを満足させる • あなたが PSP プロセスのユーザである • あなたの顧客は以下である • あなたの管理者 • あなたの同僚や仲間 • 製品のユーザ

  6. PSP での品質の焦点 - 1 • このコースでは欠陥は基本的な品質尺度である • バグは以下のような状況にならない限り、ユーザにとっては重要でないことに留意する • 運用に影響する • 不便さを引き起こす • 時間やお金を費やさせる • プログラムの結果に対する信頼を失わせる

  7. PSP での品質の焦点 - 2 • ソフトウエア製品の欠陥内容は他の多くの重要な品質 問題が扱われる前に最初に管理しなければならない。 • 現行のソフトウエアプロセスは欠陥の管理が非常にまずいため、次のような重要なソフトウエア品質問題に対して、ほとんど時間が使われることはない。 • 導入容易性 • 安全性 • 性能 • 回復性 • 使用性 など

  8. PSP での品質の焦点 - 3 • 製品中の欠陥が少ないことは、品質のよいソフトウエア プロセスに対する本質的な前提条件である。 • 製品中の欠陥を少なくすることは、このPSPレベルで最もよく達成されされることである。 • ここ(PSPレベル)が欠陥が作り込まれるところであり、ここで技術者は以下を行うべきである。 • 欠陥の除去 • 原因の決定 • 欠陥予防の学習

  9. テストとインスペクション - 1 • インスペクションを行わないと、 50,000行のシステムは • テスト開始時に25件/KL以上の欠陥を含む • 即ち、1250件以上の欠陥である • 普通、摘出には 10時間/欠陥 以上かかる、即ち 12,500 プログラマ時間以上かかる • 即ち、6 人年以上かかる • もし適切にテストが計画されると、12 から 15 ヶ月でテストを行うことができよう。 • もし計画しないと、テストに2年やそれ以上かけることになろう。

  10. テストとインスペクション - 2 • インスペクションを行うと、 50,000行のシステムは • インスペクションに約 10 人時/250行かかる、即ち 約2,000 時間かかる • 即ち、1 人年かかる • もしインスペクションをうまく実施すれば、欠陥の約 80% を除去できる • これは 250 件の欠陥がテストに残されることを意味する。 • テストに約 2,500 時間かかる • 即ち、8,000 時間の節約になる • 即ち、4 人年の節約になる

  11. テストとインスペクション - 3 • PSPを使うと • コードの品質が急激に改善されるだろう • そして恐らく数千時間が節約されよう • インスペクションはなお行うべきである • インスペクションは焦点を設計に当てるべきである • 主な利点は以下である • 製品品質が改善される • スケジュールがより予測可能になる • 重要な品質問題に時間を集中できる

  12. 修正時間データの例 • 代表的な修正時間割合の例 • IBM の経験値: コーディング - 1.5; テスト - 60; 運用 - 100 • Boehm: 設計 - 1; 開発テスト - 15 ~ 40; 受入れ テスト - 30 ~ 70; 運用 - 40 ~ 1000 • Remus: 設計 - 1, コーディング - 20, テスト - 82 • Ackerman: テストはインスペクション時間の 2 - 10 倍 • Russell: インスペクション - 1, テスト - 2 ~ 4, 運用 - 33 • PSP 研究: 単体テストは、欠陥を発見し修正するのに、コードレビューでかかる時間の12倍を要する

  13. 品質のコスト (COQ) - 1 • COQ はプロセスの品質を測定する1つの方法である。 • COQ は次の構成要素を持つ • 失敗コスト (F) • 評価コスト (A) • 予防コスト

  14. 品質のコスト (COQ) - 2 • 失敗コスト • 訂正(repair), 再作業, スクラップ • PSPでは、失敗コストはコンパイルとテストの全時間を含む • 評価コスト • 欠陥を求めてインスペクションするコスト • PSPでは, 評価コストは設計レビュー、コードレビューの全時間を含む

  15. 品質のコスト (COQ) - 3 • 予防コスト • 欠陥原因の発見と解決 • 一般にプロジェクトの開始前に処理される • 一般には組織のプロセス活動とすべきであり、プロジェクト活動とすべきではない • PSPでは, 以下が予防コストの例である • 形式的仕様化や形式的設計の作業 • プロトタイピング • プロセスの分析と改善

  16. 品質のコスト (COQ) - 4 • 役に立つ COQ 尺度に失敗コストに対する評価コストの比率 (A/FR)がある。 • 100*(評価 COQ)/(失敗 COQ) • A/FR の経験 • A/FR 尺度はそれほど広く使われていない • もし測定したなら、多くのソフトウェア組織はゼロに 近いであろう • PSPでは、A/FR は 2.0 を越えるべきである • A/FR の値が大きいというのは、テスト時の欠陥数が少なかったり、製品品質が高いことに関連している

  17. 品質戦略 - 1 • 自分の PSP の品質目標を確認する。即ち、 • 最初のコンパイル前に全ての欠陥を除去すること • 高生産性を達成すること • 正確な計画を作成すること • PSP のプロセス品質の尺度を設定する。即ち、 • 全体的なプロセスの欠陥摘出率 • COQ 評価コスト 対 失敗コスト - A/FR • 1時間当たりのレビュー行数 • コストパフォーマンス指標- CPI

  18. 品質戦略 - 2 • 完了したプロジェクトを調べる • 各尺度の結果に対する格付けを決める • これらの結果に影響を与えた活動が何かを調べる • これらのデータに基づいて、自分の仕事に最も効果的なプラクティスを確認する • これらのプラクティスを自分のプロセスに組み入れる • プロセススクリプト • チェックリスト • 帳票

  19. 品質戦略 - 3 • プロセス品質を適切に予測する尺度を確認する • これらの尺度を制御変数として確立する • これらの変数に対する仕様を設定する • これらの仕様に対する実績(performance)を追跡 する • 以下を決めるために自分のプロセスを追跡する • その仕様を変更する必要があるかどうか、必要ならいつ変更すべきか • そのプロセスをより改善するために取るべき処置

  20. プロセスのベンチマーキング • プロセス改善を追跡する方法は以下であるべきである • 品質と生産性を考慮する • 異なる人や組織が使用するプロセスを比較する手段を提供する • プロジェクト固有の事項に低感度である • 業界でのプロセスのベンチマーキングでは、概して次のようなプロセスの能力を取り扱う • 仕様の範囲内で製品を作成する • 惰性と混乱に抵抗する

  21. ソフトウェアのベンチマーキング • 現在、ソフトウェアのベンチマーキング技法はプロセスに依存している • しかしながら次を行う限り、それらの技法はなお有効である • 客観的尺度を設定する • それらを継続して追跡する • 技法を、それが対象としたプロセスの改善目的に 使用する • プロセスに敏感なベンチマークを使って個人間や組織間の比較を行うべきではない

  22. ソフトウェアのベンチマークの使用 • プロセスの実績(performance)を査定するための一貫した尺度を設定する • 全てのプロジェクトでこれらの尺度を採用する • 傾向や問題を知るためにプロジェクト間で比較する • これらの尺度に対する短期改善目標を設定して追跡する • これらの尺度に対する長期改善目標を設定して追跡する

  23. ベンチマーキングデータ • 次のデータは1994年春にカーネギーメロン大学の PSP コースを受講した学生のものである • 次のデータがある • プロジェクトごとの欠陥摘出率 • 欠陥摘出率 対 A/FR • A/FR 対 テスト時の欠陥数 • プロジェクトごとの生産性 • 欠陥摘出率 対 生産性 • A/FR 対 生産性

  24. クラス最大 クラス最小

  25. クラス最大 クラス最小

  26. 欠陥摘出率 対 A/FR の結論 • 欠陥摘出率と A/FR は • これらの学生個別にみると密接に関連している • 学生間ではかなりの変動がある • A/FR の値が大きいと、欠陥摘出率が高くなることがわかる • 70% 以上の欠陥摘出率は A/FR が 1.0 近くかそれ以上でないと達成しない。 • A/FR の値が大きくても欠陥摘出率が高くなることを保証しない - 評価時間を効果的に使わなければ  ならない

  27. テスト時の欠陥数 対 A/FR の結論 • 全ての学生において、A/FR の値を大きくすると欠陥数が減少している • テスト時の欠陥数を非常に小さい値にするためには、2.0 以上の A/FR の値が必要であることがわかる • A/FR の値が 1.0 ~ 2.0 であれば、テスト時の欠陥数は時折少なくなる • A/FR の値が 1.0 以下のときは、テスト時の欠陥数が少なくなるのは稀である

  28. クラスの最大 クラスの最小

  29. クラスの最大 クラスの最小

  30. 欠陥摘出率 対 生産性、A/FR 対 生産性 の結論 • 生産性は個人間でかなりの変動がある • いくつかのケースで、欠陥摘出率が高いと生産性が より高くなることもあったが、別のケースではそうではなかった • A/FR も値が大きいと生産性が高くなることもあるが、そうでないこともある • 明らかに、欠陥摘出率および A/FR は生産性とは  やや無関係である

  31. ベンチマークの結論 • 以下の尺度は値が大きいほど望ましい • 欠陥摘出率 • 失敗コストに対する評価コストの比率(A/FR) • 生産性 • 欠陥摘出率と A/FR とは密接に関連しているので、欠陥摘出率 対 A/FR の図を作成してもベンチマーキングには役立たないであろう • 一方、欠陥摘出率 対 生産性、A/FR 対 生産性 の図はベンチマーキングに役立つであろう

  32. 欠陥除去戦略 - 1 • インスペクションとレビューの焦点をそれぞれ特化した分野にあてる • 概要設計レビュー - 構造的な問題 • 詳細設計レビュー - 論理の正しさ • コードレビュー - 実現の詳細事項 • 時間を節約するため、以下は取り扱わない • 詳細設計レビューでシステム問題 • コードレビューで設計問題 • レビューは第1回目に徹底的に行いなさい、そしてレビューを信用しなさい。

  33. 欠陥除去戦略 - 2 • 単体テストを徹底的に行いなさい • 全てのパラメータを正常値、限界値、限界外の値でチェックする • 全てのループや反復を正常終了、異常終了した 場合についてチェックする • 全ての 依存関係 をプロシージャ間、オブジェクト間でチェックする • 次にシステムレベルのテストを徹底的に行いなさい • 統合テスト • システムテスト • リグレッションテスト

  34. 欠陥予防 • 欠陥予防は以下の理由で重要である • 欠陥を発見するのは常に高価である • もし欠陥を予防できれば、これらのコストが避けられる • 欠陥予防の分析コストは一度しかかからないが、 これにより全てのプロジェクトで時間を節約できる。 • 欠陥予防は秩序正しい戦略と定義されたプロセスに従って行うべきである • PSPでは、欠陥予防の処置として設計手法の改善やプロトタイピングを含む

  35. 欠陥予防戦略 - 1 • 次の視点から欠陥の型に優先順位を付ける • 最も頻繁に発見される欠陥 • 最も厄介な欠陥 • 最も容易に予防できる欠陥

  36. 欠陥予防戦略 - 2 • 欠陥予防プロセスは次のステップを持つ: • 1. 確立されたスケジュールに従う • 2. 最初の活動として1つか2つの欠陥の型を選ぶ • 3. 欠陥予防処置の有効性を追跡して査定する • 4. 必要な調整を行い、継続する

  37. 欠陥予防戦略 - 3 • 最初の優先順位付けの際には、統合テストおよびシステムテストで最も頻繁に発見される欠陥の型を考慮しなさい • PSP データを使って、最初の活動のために1つか 2つの欠陥の型を選びなさい • ただただもっと一生懸命やるのではなく、明確な 予防処置を確立しなさい • これらの処置をプロセススクリプト、チェックリスト、帳票に組み入れなさい

  38. 演習課題 #8 • テキストの 9 章を読みなさい • PSP2 を使って、2系列の数値の間の相関を計算し、その相関の有意性を計算するプログラム 7A を作成しなさい • t 分布の値を計算するのにプログラム 5A を使いなさい • PSP2 の説明は付録C(p.389-394, 445-453)を、プログラム 7A の仕様は付録D(p.492)を参考にしなさい

More Related