Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 1
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 2
講義の概要 品質とは何か?
•製品と の品質プロセス•品質の経済学
品質戦略• の特徴づけプロセス• のプロセス ベンチマーキング
欠陥摘出の管理•欠陥除去•欠陥予防
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 3
品質とは何か? ソフト 基本的定義
•ユーザのニーズを満たすこと•ニーズであり、ウォンツではない•真の機能的なニーズはしばしば知り得ないものである
ニーズの階層•要求されたタスクを行う•性能要求を満足させる•利用しやすく便利であること•経済的でタイムリーなこと•頼りになり信頼できること
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 4
頼りになり信頼できこと 使われるためにソフトウェアは以下でなければならない•速く容易にインストールできる•矛盾無く稼働する•正常ケース、異常ケースを適切に扱う•破壊的なことや予期しないことは行わない•本質的にはバグがない
潜在バグは以下でなければならない•運用上の影響が小さい•破壊的でない•顕在化するのは稀である
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 5
品質の良いプロセス
品質のよい製品を作る
プロセスのユーザのニーズを満足させる
あなたが PSP プロセスのユーザである
あなたの顧客は以下である•あなたの管理者•あなたの同僚や仲間•製品のユーザ
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 6
PSP での品質の焦点 - 1
このコースでは欠陥は基本的な品質尺度である
バグは以下のような状況にならない限り、ユーザにとっては重要でないことに留意する•運用に影響する•不便さを引き起こす•時間やお金を費やさせる•プログラムの結果に対する信頼を失わせる
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 7
PSP での品質の焦点 - 2 製品の欠陥内容は他の多くの重要な品質 ソフトウエア問題が扱われる前に最初に管理しなければならない。
現行の は欠陥の管理が非常にまずいソフトウエアプロセスため、次のような重要な 品質問題に対してソフトウエア、ほとんど時間が使われることはない。•導入容易性•安全性•性能•回復性•使用性 など
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 8
PSP での品質の焦点 - 3 製品中の欠陥が少ないことは、品質のよいソフトウエア に対する本質的な前提条件である。プロセス
製品中の欠陥を少なくすることは、この PSP レベルで最もよく達成されされることである。
ここ (PSP レベル ) が欠陥が作り込まれるところであり、ここで技術者は以下を行うべきである。•欠陥の除去•原因の決定•欠陥予防の学習
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 9
と テスト インスペクション - 1 を行わないと、 インスペクション 50,000 行の はシステム
• 開始時にテスト 25 件 /KL 以上の欠陥を含む•即ち、 1250 件以上の欠陥である•普通、摘出には 10 時間 / 欠陥 以上かかる、即ち 12,500 時間以上かかる プログラマ
•即ち、 6 人年以上かかる
もし適切に が計画されると、テスト 12 から 15 ヶ月で を行うことができよう。テスト
もし計画しないと、 に2年やそれ以上かけテストることになろう。
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 10
と テスト インスペクション - 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 11
と テスト インスペクション - 3 PSP を使うと
•コードの品質が急激に改善されるだろう•そして恐らく数千時間が節約されよう
はなお行うべきであるインスペクション• は焦点を設計に当てるべきであるインスペクション
主な利点は以下である•製品品質が改善される• がより予測可能になるスケジュール•重要な品質問題に時間を集中できる
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 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倍を要するコードレビュー
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 13
品質のコスト (COQ) - 1
COQ はプロセスの品質を測定する1つの方法である。
COQ は次の構成要素を持つ•失敗コスト (F)•評価コスト (A)•予防コスト
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 14
品質のコスト (COQ) - 2 失敗コスト
•訂正( repair) , 再作業 , スクラップ•PSP では、失敗コストはコンパイルとテストの全時間を含む
評価コスト•欠陥を求めて するコストインスペクション•PSP では , 評価コストは設計 、レビュー コードレビューの全時間を含む
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 15
品質のコスト (COQ) - 3
予防コスト•欠陥原因の発見と解決•一般にプロジェクトの開始前に処理される•一般には組織のプロセス活動とすべきであり、プロジェクト活動とすべきではない
PSP では , 以下が予防コストの例である•形式的仕様化や形式的設計の作業•プロトタイピング•プロセスの分析と改善
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 16
品質のコスト (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 17
品質戦略 - 1
自分の PSP の品質目標を確認する。即ち、•最初のコンパイル前に全ての欠陥を除去すること
•高生産性を達成すること•正確な計画を作成すること
PSP のプロセス品質の尺度を設定する。即ち、•全体的なプロセスの欠陥摘出率•COQ 評価コスト 対 失敗コスト - A/FR•1時間当たりの 行数レビュー• 指標コストパフォーマンス - CPI
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 18
品質戦略 - 2 完了したプロジェクトを調べる
•各尺度の結果に対する格付けを決める•これらの結果に影響を与えた活動が何かを調べる
これらのデータに基づいて、自分の仕事に最も効果的な を確認するプラクティス
これらの を自分のプロセスに組み入れるプラクティス•プロセススクリプト•チェックリスト•帳票
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 19
品質戦略 - 3 プロセス品質を適切に予測する尺度を確認する
•これらの尺度を制御変数として確立する•これらの変数に対する仕様を設定する
これらの仕様に対する実績( performance)を追跡 する
以下を決めるために自分のプロセスを追跡する•その仕様を変更する必要があるかどうか、必要ならいつ変更すべきか
•そのプロセスをより改善するために取るべき処置
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 20
プロセスのベンチマーキング
プロセス改善を追跡する方法は以下であるべきである•品質と生産性を考慮する•異なる人や組織が使用するプロセスを比較する手段を提供する
•プロジェクト固有の事項に低感度である
業界でのプロセスのベンチマーキングでは、概して次のようなプロセスの能力を取り扱う•仕様の範囲内で製品を作成する•惰性と混乱に抵抗する
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 21
ソフトウェアのベンチマーキング 現在、ソフトウェアのベンチマーキング技法はプロセスに依存している
しかしながら次を行う限り、それらの技法はなお有効である•客観的尺度を設定する•それらを継続して追跡する•技法を、それが対象としたプロセスの改善目的に 使用する
プロセスに敏感なベンチマークを使って個人間や組織間の比較を行うべきではない
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 22
ソフトウェアのベンチマークの使用
プロセスの実績( performance)を査定するための一貫した尺度を設定する•全てのプロジェクトでこれらの尺度を採用する•傾向や問題を知るためにプロジェクト間で比較する
これらの尺度に対する短期改善目標を設定して追跡する
これらの尺度に対する長期改善目標を設定して追跡する
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 23
ベンチマーキングデータ
次のデータは 1994 年春に 大学の カーネギーメロン PSP コースを受講した学生のものである
次のデータがある•プロジェクトごとの欠陥摘出率•欠陥摘出率 対 A/FR•A/FR 対 テスト時の欠陥数•プロジェクトごとの生産性•欠陥摘出率 対 生産性•A/FR 対 生産性
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 24
欠陥摘出率 - 学生 3
0
20
40
60
80
100
0 1 2 3 4 5 6 7 8 9 10 11
フ ロ゚ク ラ゙ム 番号
欠陥
摘出率
クラス最大
クラス最小
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 25
欠陥摘出率 - 学生 20
0
20
40
60
80
100
0 1 2 3 4 5 6 7 8 9 10 11
フ ロ゚ク ラ゙ム 番号
欠陥
摘出率
クラス最大
クラス最小
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 26
欠陥摘出率 対 A/FR - 学生 3
0
20
40
60
80
100
0 1 2 3 4
失敗コストに対する評価コストの比率 -A/FR
欠陥
摘出率
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 27
欠陥摘出率 対 A/FR - 学生 20
0
20
40
60
80
100
0 1 2 3
失敗コストに対する評価コストの比率 -A/FR
欠陥
摘出率
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 28
欠陥摘出率 vs. A/FR -
全学生、全フ ロ゚ク ラ゙ム
0
20
40
60
80
100
0 1 2 3 4 5
失敗コストに対する評価コストの比率 -A/FR
欠陥
摘出率
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 29
欠陥摘出率 対 A/FR の結論
欠陥摘出率と A/FR は•これらの学生個別にみると密接に関連している•学生間ではかなりの変動がある
A/FR の値が大きいと、欠陥摘出率が高くなることがわかる•70% 以上の欠陥摘出率は A/FR が 1.0 近くかそれ以上でないと達成しない。
•A/FR の値が大きくても欠陥摘出率が高くなることを保証しない - 評価時間を効果的に使わなければ ならない
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 30
テスト時の欠陥数 対 A/FR -学生3
0
5
10
15
20
25
30
35
40
0 1 2 3 4
失敗コストに対する評価コストの比率
テス
ト時
の欠
陥数/K
LO
C
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 31
テスト時の欠陥数 対 A/FR -学生20
0
5
10
15
20
25
30
35
40
0 1 2 3
失敗コストに対する評価コストの比率
テス
ト時
の欠
陥数/K
LO
C
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 32
テスト時の欠陥数 対 A/FR -クラス
0
20
40
60
80
100
120
140
160
180
0 1 2 3 4 5
失敗コストに対する評価コストの比率
テス
ト時
の欠
陥数/K
LO
C
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 33
テスト時の欠陥数 対 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 34
生産性の傾向 - 学生3
0
1020
3040
50
6070
8090
100
1 2 3 4 5 6 7 8 9 10
フ ロ゚ク ラ゙ム 番号
LO
C/ 時
間
クラスの最大
クラスの最小
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 35
生産性の傾向 - 学生20
0
10
20
30
40
5060
70
80
90
100
1 2 3 4 5 6 7 8 9 10
フ ロ゚ク ラ゙ム 番号
LO
C/ 時
間
クラスの最大
クラスの最小
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 36
欠陥摘出率 対 生産性 - 学生3
0
10
20
30
40
50
60
0 50 100
欠陥摘出率 - 早期の欠陥除去%
生産
性 -
LO
C/ 時
間
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 37
欠陥摘出率 対 生産性 - 学生20
0
10
20
30
40
0 50 100
欠陥摘出率 - 早期の欠陥除去%
生産
性 -
LO
C/ 時
間
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 38
欠陥摘出率 対 生産性 -
全ての学生、全てのフ ロ゚ク ラ゙ム
0
20
40
60
80
100
0 50 100
欠陥摘出率 - 早期の欠陥除去%
生産
性 -
LO
C/ 時
間
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 39
生産性 対 A/FR - 学生3
0
10
20
30
40
50
60
0 1 2 3 4
失敗コストに対する評価コストの比率(A/FR)
生産
性 -
LO
C/ 時
間
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 40
生産性 対 A/FR - 学生20
0
5
10
15
20
25
30
35
40
0 1 2 3
A/FR
生産
性 -
LO
C/ 時
間
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 41
生産性 対 A/FR - 全ての学生、全てのフ ロ゚ク ラ゙ ム
0
20
40
60
80
100
0 2 4 6
A/FR
生産
性 -
LO
C/ 時
間
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 42
欠陥摘出率 対 生産性、A/FR 対 生産性 の結論
生産性は個人間でかなりの変動がある
いくつかのケースで、欠陥摘出率が高いと生産性が より高くなることもあったが、別のケースではそうではなかった
A/FR も値が大きいと生産性が高くなることもあるが、そうでないこともある
明らかに、欠陥摘出率および A/FR は生産性とは やや無関係である
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 43
ベンチマークの結論 以下の尺度は値が大きいほど望ましい
•欠陥摘出率•失敗コストに対する評価コストの比率( A/FR)
•生産性
欠陥摘出率と A/FR とは密接に関連しているので、欠陥摘出率 対 A/FR の図を作成してもベンチマーキングには役立たないであろう
一方、欠陥摘出率 対 生産性、 A/FR 対 生産性 の図はベンチマーキングに役立つであろう
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 44
欠陥除去戦略 - 1 と の焦点をそれぞれ特化した分野にインスペクション レビューあてる•概要設計 レビュー - 構造的な問題•詳細設計 レビュー - 論理の正しさ• コードレビュー - 実現の詳細事項
時間を節約するため、以下は取り扱わない•詳細設計 でシステム問題レビュー• で設計問題コードレビュー
は第1回目に徹底的に行いなさい、そしてレビュー レビを信用しなさい。ュー
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 45
欠陥除去戦略 - 2 単体テストを徹底的に行いなさい
•全てのパラメータを正常値、限界値、限界外の値でチェックする
•全てのループや反復を正常終了、異常終了した 場合についてチェックする
•全ての 依存関係 を 間、 間でチプロシージャ オブジェクトェックする
次にシステムレベルのテストを徹底的に行いなさい•統合テスト•システムテスト•リグレッションテスト
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 46
欠陥予防 欠陥予防は以下の理由で重要である
•欠陥を発見するのは常に高価である•もし欠陥を予防できれば、これらのコストが避けられる
•欠陥予防の分析コストは一度しかかからないが、 これにより全てのプロジェクトで時間を節約できる。
欠陥予防は秩序正しい戦略と定義されたプロセスに従って行うべきである
PSP では、欠陥予防の処置として設計手法の改善やプロトタイピングを含む
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 47
欠陥予防戦略 - 1
次の視点から欠陥の型に優先順位を付ける•最も頻繁に発見される欠陥•最も厄介な欠陥•最も容易に予防できる欠陥
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 48
欠陥予防戦略 - 2
欠陥予防プロセスは次のステップを持つ :
1. 確立されたスケジュールに従う 2. 最初の活動として1つか2つの欠陥の型を選ぶ 3. 欠陥予防処置の有効性を追跡して査定する 4. 必要な調整を行い、継続する
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 49
欠陥予防戦略 - 3
最初の優先順位付けの際には、統合テストおよびシステムテストで最も頻繁に発見される欠陥の型を考慮しなさい
PSP データを使って、最初の活動のために1つか 2つの欠陥の型を選びなさい
ただただもっと一生懸命やるのではなく、明確な 予防処置を確立しなさい
これらの処置をプロセススクリプト、チェックリスト、帳票に組み入れなさい
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 50
演習課題 #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 51
相関 相関係数 r の計算公式
ただし•x と y は 2組のデータ集合である•n はデータ数である
r x, y n xi yii1
n
x ii1
n
yii1
n
n x i2
i1
n
x ii1
n
2
n yi
2
i1
n
yii1
n
2
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 52
相関の有意性 相関の有意性の計算公式
ここで•r は相関•t 分布の値 t に対する p の値を計算するために プログラム 5A を使いなさい
•有意性は 1 - p で示される•> 0.2 は有意ではない、 < 0.05 は有意である
t r x,y n 2
1 r x, y 2
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 8 53
講義 8 のまとめ - 1
1. ソフトウェアの品質は欠陥で始まる
2. もし欠陥が管理されないと、より重要な品質問題が
適切に取り扱えない