jlect08

Disciplined Software
Engineering
Lecture #8
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Sponsored by the U.S. Department of Defense
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 1
講義の概要
品質とは何か？
•製品とﾌﾟﾛｾｽの品質
•品質の経済学
品質戦略
•ﾌﾟﾛｾｽの特徴づけ
•ﾌﾟﾛｾｽのﾍﾞﾝﾁﾏｰｷﾝｸﾞ
欠陥摘出の管理
•欠陥除去
•欠陥予防
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 2
ｿﾌﾄ品質とは何か？
基本的定義
•ユーザのニーズを満たすこと
•ニーズであり、ウォンツではない
•真の機能的なニーズはしばしば知り得ないもので
ある
ニーズの階層
•要求されたタスクを行う
•性能要求を満足させる
•利用しやすく便利であること
•経済的でタイムリーなこと
•頼りになり信頼できること
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 3
頼りになり信頼できこと
使われるためにソフトウェアは以下でなければならない
•速く容易にインストールできる
•矛盾無く稼働する
•正常ケース、異常ケースを適切に扱う
•破壊的なことや予期しないことは行わない
•本質的にはバグがない
潜在バグは以下でなければならない
•運用上の影響が小さい
•破壊的でない
•顕在化するのは稀である
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 4
品質の良いプロセス
品質のよい製品を作る
プロセスのユーザのニーズを満足させる
あなたが PSP プロセスのユーザである
あなたの顧客は以下である
•あなたの管理者
•あなたの同僚や仲間
•製品のユーザ
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 5
PSP での品質の焦点 - 1
このコースでは欠陥は基本的な品質尺度である
バグは以下のような状況にならない限り、ユーザに
とっては重要でないことに留意する
•運用に影響する
•不便さを引き起こす
•時間やお金を費やさせる
•プログラムの結果に対する信頼を失わせる
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 6
PSP での品質の焦点 - 2
ｿﾌﾄｳｴｱ製品の欠陥内容は他の多くの重要な品質
問題が扱われる前に最初に管理しなければならない｡
現行のｿﾌﾄｳｴｱﾌﾟﾛｾｽは欠陥の管理が非常にまずい
ため、次のような重要なｿﾌﾄｳｴｱ品質問題に対して、
ほとんど時間が使われることはない。
•導入容易性
•安全性
•性能
•回復性
•使用性など
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 7
PSP での品質の焦点 - 3
製品中の欠陥が少ないことは、品質のよいｿﾌﾄｳｴｱ
ﾌﾟﾛｾｽに対する本質的な前提条件である。
製品中の欠陥を少なくすることは、このPSPレベルで
最もよく達成されされることである。
ここ(PSPレベル)が欠陥が作り込まれるところであり、
ここで技術者は以下を行うべきである。
•欠陥の除去
•原因の決定
•欠陥予防の学習
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 8
ﾃｽﾄとｲﾝｽﾍﾟｸｼｮﾝ - 1
ｲﾝｽﾍﾟｸｼｮﾝを行わないと、 50,000行のｼｽﾃﾑは
•ﾃｽﾄ開始時に25件/KL以上の欠陥を含む
•即ち、1250件以上の欠陥である
•普通、摘出には 10時間/欠陥以上かかる、即ち
12,500 ﾌﾟﾛｸﾞﾗﾏ時間以上かかる
•即ち、6 人年以上かかる
もし適切にﾃｽﾄが計画されると、12 から 15 ヶ月でﾃ
ｽﾄを行うことができよう。
もし計画しないと、ﾃｽﾄに２年やそれ以上かけること
になろう。
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 9
ﾃｽﾄとｲﾝｽﾍﾟｸｼｮﾝ - 2
ｲﾝｽﾍﾟｸｼｮﾝを行うと、 50,000行のｼｽﾃﾑは
•ｲﾝｽﾍﾟｸｼｮﾝに約 10 人時/250行かかる、即ち約2,000
時間かかる
•即ち、1 人年かかる
•もしｲﾝｽﾍﾟｸｼｮﾝをうまく実施すれば、欠陥の約 80% を
除去できる
これは 250 件の欠陥がﾃｽﾄに残されることを意味する。
•ﾃｽﾄに約 2,500 時間かかる
•即ち、8,000 時間の節約になる
•即ち、4 人年の節約になる
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 10
ﾃｽﾄとｲﾝｽﾍﾟｸｼｮﾝ - 3
PSPを使うと
•コードの品質が急激に改善されるだろう
•そして恐らく数千時間が節約されよう
ｲﾝｽﾍﾟｸｼｮﾝはなお行うべきである
•ｲﾝｽﾍﾟｸｼｮﾝは焦点を設計に当てるべきである
主な利点は以下である
•製品品質が改善される
•ｽｹｼﾞｭｰﾙがより予測可能になる
•重要な品質問題に時間を集中できる
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 11
修正時間データの例
代表的な修正時間割合の例
•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 研究: 単体テストは、欠陥を発見し修正するの
に、ｺｰﾄﾞﾚﾋﾞｭｰでかかる時間の１２倍を要する
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 12
品質のコスト (COQ) - 1
COQ はプロセスの品質を測定する１つの方法である。
COQ は次の構成要素を持つ
•失敗コスト (F)
•評価コスト (A)
•予防コスト
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 13
品質のコスト (COQ) - 2
失敗コスト
•訂正（repair）, 再作業, ｽｸﾗｯﾌﾟ
•PSPでは、失敗コストはコンパイルとテストの全時間
を含む
評価コスト
•欠陥を求めてｲﾝｽﾍﾟｸｼｮﾝするコスト
•PSPでは, 評価コストは設計ﾚﾋﾞｭｰ、ｺｰﾄﾞﾚﾋﾞｭｰの全
時間を含む
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 14
品質のコスト (COQ) - 3
予防コスト
•欠陥原因の発見と解決
•一般にプロジェクトの開始前に処理される
•一般には組織のプロセス活動とすべきであり、
プロジェクト活動とすべきではない
PSPでは, 以下が予防コストの例である
•形式的仕様化や形式的設計の作業
•プロトタイピング
•プロセスの分析と改善
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 15
品質のコスト (COQ) - 4
役に立つ COQ 尺度に失敗コストに対する評価コスト
の比率 (A/FR)がある。
•100*(評価 COQ)/(失敗 COQ)
A/FR の経験
•A/FR 尺度はそれほど広く使われていない
•もし測定したなら、多くのソフトウェア組織はゼロに
近いであろう
•PSPでは、A/FR は 2.0 を越えるべきである
•A/FR の値が大きいというのは、テスト時の欠陥数が
少なかったり、製品品質が高いことに関連している
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 16
品質戦略 - 1
自分の PSP の品質目標を確認する。即ち、
•最初のコンパイル前に全ての欠陥を除去すること
•高生産性を達成すること
•正確な計画を作成すること
PSP のプロセス品質の尺度を設定する。即ち、
•全体的なプロセスの欠陥摘出率
•COQ 評価コスト対失敗コスト - A/FR
•１時間当たりのﾚﾋﾞｭｰ行数
•ｺｽﾄﾊﾟﾌｫｰﾏﾝｽ指標- CPI
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 17
品質戦略 - 2
完了したプロジェクトを調べる
•各尺度の結果に対する格付けを決める
•これらの結果に影響を与えた活動が何かを調べる
これらのデータに基づいて、自分の仕事に最も効果的
なﾌﾟﾗｸﾃｨｽを確認する
これらのﾌﾟﾗｸﾃｨｽを自分のプロセスに組み入れる
•プロセススクリプト
•チェックリスト
•帳票
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 18
品質戦略 - 3
プロセス品質を適切に予測する尺度を確認する
•これらの尺度を制御変数として確立する
•これらの変数に対する仕様を設定する
これらの仕様に対する実績（performance）を追跡
する
以下を決めるために自分のプロセスを追跡する
•その仕様を変更する必要があるかどうか、必要なら
いつ変更すべきか
•そのプロセスをより改善するために取るべき処置
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 19
プロセスのベンチマーキング
プロセス改善を追跡する方法は以下であるべきである
•品質と生産性を考慮する
•異なる人や組織が使用するプロセスを比較する手段
を提供する
•プロジェクト固有の事項に低感度である
業界でのプロセスのベンチマーキングでは、概して次
のようなプロセスの能力を取り扱う
•仕様の範囲内で製品を作成する
•惰性と混乱に抵抗する
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 20
ソフトウェアのベンチマーキング
現在、ソフトウェアのベンチマーキング技法はプロセス
に依存している
しかしながら次を行う限り、それらの技法はなお有効で
ある
•客観的尺度を設定する
•それらを継続して追跡する
•技法を、それが対象としたプロセスの改善目的に
使用する
プロセスに敏感なベンチマークを使って個人間や組織
間の比較を行うべきではない
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 21
ソフトウェアのベンチマークの使用
プロセスの実績（performance）を査定するための一
貫した尺度を設定する
•全てのプロジェクトでこれらの尺度を採用する
•傾向や問題を知るためにプロジェクト間で比較する
これらの尺度に対する短期改善目標を設定して追跡
する
これらの尺度に対する長期改善目標を設定して追跡
する
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 22
ベンチマーキングデータ
次のデータは1994年春にｶｰﾈｷﾞｰﾒﾛﾝ大学の PSP
コースを受講した学生のものである
次のデータがある
•プロジェクトごとの欠陥摘出率
•欠陥摘出率対 A/FR
•A/FR 対テスト時の欠陥数
•プロジェクトごとの生産性
•欠陥摘出率対生産性
•A/FR 対生産性
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 23
欠陥摘出率 - 学生 3
100
欠陥摘出率
80
60
クラス最大
40
クラス最小
20
0
0
1
2
3
4
5
6
7
8
9
10 11
ﾌﾟﾛｸﾞﾗﾑ番号
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 24
欠陥摘出率 - 学生 20
100
欠陥摘出率
80
60
クラス最大
40
20
クラス最小
0
0
1
2
3
4
5
6
7
8
9
10 11
ﾌﾟﾛｸﾞﾗﾑ番号
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 25
欠陥摘出率対 A/FR - 学生 3
100
欠陥摘出率
80
60
40
20
0
0
1
2
3
失敗コストに対する評価コストの比率
A/FR
Copyright © 1994 Carnegie Mellon University
4
-
Disciplined Software Engineering - Lecture 8 26
欠陥摘出率対 A/FR - 学生 20
100
欠陥摘出率
80
60
40
20
0
0
1
2
失敗コストに対する評価コストの比率
A/FR
Copyright © 1994 Carnegie Mellon University
3
-
Disciplined Software Engineering - Lecture 8 27
欠陥摘出率 vs. A/FR 全学生、全ﾌﾟﾛｸﾞﾗﾑ
100
欠陥摘出率
80
60
40
20
0
0
1
2
3
4
失敗コストに対する評価コストの比率
A/FR
Copyright © 1994 Carnegie Mellon University
5
-
Disciplined Software Engineering - Lecture 8 28
欠陥摘出率対 A/FR の結論
欠陥摘出率と A/FR は
•これらの学生個別にみると密接に関連している
•学生間ではかなりの変動がある
A/FR の値が大きいと、欠陥摘出率が高くなることがわ
かる
•70% 以上の欠陥摘出率は A/FR が 1.0 近くかそれ
以上でないと達成しない。
•A/FR の値が大きくても欠陥摘出率が高くなることを
保証しない - 評価時間を効果的に使わなければ
ならない
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 29
テスト時の欠陥数 /KLOC
テスト時の欠陥数対 A/FR 学生 3
40
35
30
25
20
15
10
5
0
0
1
2
3
4
失敗コストに対する評価コストの比率
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 30
テスト時の欠陥数 /KLOC
テスト時の欠陥数対 A/FR 学生 20
40
35
30
25
20
15
10
5
0
0
1
2
3
失敗コストに対する評価コストの比率
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 31
テスト時の欠陥数 /KLOC
テスト時の欠陥数対 A/FR クラス
180
160
140
120
100
80
60
40
20
0
0
1
2
3
4
5
失敗コストに対する評価コストの比率
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 32
テスト時の欠陥数対 A/FR の結論
全ての学生において、A/FR の値を大きくすると欠陥数
が減少している
テスト時の欠陥数を非常に小さい値にするためには、
2.0 以上の A/FR の値が必要であることがわかる
A/FR の値が 1.0 ～ 2.0 であれば、テスト時の欠陥数
は時折少なくなる
A/FR の値が 1.0 以下のときは、テスト時の欠陥数が
少なくなるのは稀である
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 33
LOC/時間
生産性の傾向 - 学生 3
100
90
80
70
60
50
40
30
20
10
0
クラスの最大
クラスの最小
1
2
3
4
5
6
7
8
9
10
ﾌﾟﾛｸﾞﾗﾑ番号
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 34
LOC/時間
生産性の傾向 - 学生 20
100
90
80
70
60
50
40
30
20
10
0
クラスの最大
クラスの最小
1
2
3
4
5
6
7
8
9
10
ﾌﾟﾛｸﾞﾗﾑ番号
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 35
欠陥摘出率対生産性 - 学生 3
生産性 - LOC/時間
60
50
40
30
20
10
0
0
50
100
欠陥摘出率 - 早期の欠陥除去 %
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 36
欠陥摘出率対生産性 - 学生 20
生産性 - LOC/時間
40
30
20
10
0
0
50
100
欠陥摘出率 - 早期の欠陥除去 %
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 37
欠陥摘出率対生産性全ての学生、全てのﾌﾟﾛｸﾞﾗﾑ
生産性 - LOC/時間
100
80
60
40
20
0
0
50
100
欠陥摘出率 - 早期の欠陥除去 %
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 38
生産性対 A/FR - 学生 3
生産性 - LOC/時間
60
50
40
30
20
10
0
0
1
2
3
4
失敗コストに対する評価コストの
比率（ A/FR）
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 39
生産性対 A/FR - 学生 20
生産性 - LOC/時間
40
35
30
25
20
15
10
5
0
0
1
2
3
A/FR
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 40
生産性対 A/FR - 全ての学生、
全てのﾌﾟﾛｸﾞﾗﾑ
生産性 - LOC/時間
100
80
60
40
20
0
0
2
4
6
A/FR
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 41
欠陥摘出率対生産性、
A/FR 対生産性の結論
生産性は個人間でかなりの変動がある
いくつかのケースで、欠陥摘出率が高いと生産性が
より高くなることもあったが、別のケースではそうでは
なかった
A/FR も値が大きいと生産性が高くなることもあるが、
そうでないこともある
明らかに、欠陥摘出率および A/FR は生産性とは
やや無関係である
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 42
ベンチマークの結論
以下の尺度は値が大きいほど望ましい
•欠陥摘出率
•失敗コストに対する評価コストの比率（A/FR）
•生産性
欠陥摘出率と A/FR とは密接に関連しているので、
欠陥摘出率対 A/FR の図を作成してもベンチマーキ
ングには役立たないであろう
一方、欠陥摘出率対生産性、A/FR 対生産性の
図はベンチマーキングに役立つであろう
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 43
欠陥除去戦略 - 1
ｲﾝｽﾍﾟｸｼｮﾝとﾚﾋﾞｭｰの焦点をそれぞれ特化した分野に
あてる
•概要設計ﾚﾋﾞｭｰ - 構造的な問題
•詳細設計ﾚﾋﾞｭｰ - 論理の正しさ
•ｺｰﾄﾞﾚﾋﾞｭｰ - 実現の詳細事項
時間を節約するため、以下は取り扱わない
•詳細設計ﾚﾋﾞｭｰでシステム問題
•ｺｰﾄﾞﾚﾋﾞｭｰで設計問題
ﾚﾋﾞｭｰは第１回目に徹底的に行いなさい、そしてﾚﾋﾞｭｰ
を信用しなさい。
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 44
欠陥除去戦略 - 2
単体テストを徹底的に行いなさい
•全てのパラメータを正常値、限界値、限界外の値で
チェックする
•全てのループや反復を正常終了、異常終了した
場合についてチェックする
•全ての依存関係をﾌﾟﾛｼｰｼﾞｬ間、ｵﾌﾞｼﾞｪｸﾄ間でチェ
ックする
次にシステムレベルのテストを徹底的に行いなさい
•統合テスト
•システムテスト
•リグレッションテスト
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 45
欠陥予防
欠陥予防は以下の理由で重要である
•欠陥を発見するのは常に高価である
•もし欠陥を予防できれば、これらのコストが避けられ
る
•欠陥予防の分析コストは一度しかかからないが、
これにより全てのプロジェクトで時間を節約できる。
欠陥予防は秩序正しい戦略と定義されたプロセスに
従って行うべきである
PSPでは、欠陥予防の処置として設計手法の改善や
プロトタイピングを含む
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 46
欠陥予防戦略 - 1
次の視点から欠陥の型に優先順位を付ける
•最も頻繁に発見される欠陥
•最も厄介な欠陥
•最も容易に予防できる欠陥
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 47
欠陥予防戦略 - 2
欠陥予防プロセスは次のステップを持つ:
1. 確立されたスケジュールに従う
2. 最初の活動として１つか２つの欠陥の型を選ぶ
3. 欠陥予防処置の有効性を追跡して査定する
4. 必要な調整を行い、継続する
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 48
欠陥予防戦略 - 3
最初の優先順位付けの際には、統合テストおよび
システムテストで最も頻繁に発見される欠陥の型を
考慮しなさい
PSP データを使って、最初の活動のために１つか
２つの欠陥の型を選びなさい
ただただもっと一生懸命やるのではなく、明確な
予防処置を確立しなさい
これらの処置をプロセススクリプト、チェックリスト、
帳票に組み入れなさい
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 49
演習課題 #8
テキストの 9 章を読みなさい
PSP2 を使って、2系列の数値の間の相関を計算し、そ
の相関の有意性を計算するﾌﾟﾛｸﾞﾗﾑ 7A を作成しなさ
い
t 分布の値を計算するのにﾌﾟﾛｸﾞﾗﾑ 5A を使いなさい
PSP2 の説明は付録C(p.389-394, 445-453)を、ﾌﾟﾛｸﾞ
ﾗﾑ 7A の仕様は付録D(p.492)を参考にしなさい
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 50
相関
相関係数 r の計算公式
rx, y 
n
n
n
i1
i 1
i1
n xi yi   x i  yi
 n 2  n 2  n 2  n 2 
 x i
 yi
n
x

n
y


i

i







i
1
i
1
i
1
i
1



ただし
•x と y は2組のデータ集合である
•n はデータ数である
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 51
相関の有意性
相関の有意性の計算公式
t 
r x, y 
n2
1  r x, y 
2
ここで
•r は相関
•t 分布の値 t に対する p の値を計算するために
ﾌﾟﾛｸﾞﾗﾑ 5A を使いなさい
•有意性は 1 - p で示される
•> 0.2 は有意ではない、< 0.05 は有意である
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 52
講義 8 のまとめ - 1
1. ソフトウェアの品質は欠陥で始まる
2. もし欠陥が管理されないと、より重要な品質問題が
適切に取り扱えない
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 53
講義 8 のまとめ - 2
3. 欠陥を管理する最も効果的な方法は、個々の
ソフトウェア技術者の手にある。
4. もし自分自身の欠陥を除去しなければ、欠陥は
はるかに高価になってしまい、後で除去するのに
多くの時間を消費することになる
Copyright © 1994 Carnegie Mellon University
Disciplined Software Engineering - Lecture 8 54

Download Report