Transcript 欠陥 - 九州産業大学情報科学部

Disciplined Software
Engineering
Lecture #7
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Sponsored by the U.S. Department of Defense
Copyright © 1994 Carnegie Mellon University1
情報システムプロジェクト管理（8）
九州産業大学
情報科学部
松本研究室
Copyright © 1994 Carnegie Mellon University2
レビュー（Review）
より品質の良い情報システムを開発するため、設計や
実装などを精査し、チェックし、審査し、不具合を正すこ
と
Formal assessment or examination of
something with the intention of instituting
change
Copyright © 1994 Carnegie Mellon University3
設計レビュー とコードレビューの概要
設計レビューとコードレビューとは何か？
なぜこれらのレビューをすべきか？
ＰＳＰにおける
•レビュー戦略
•レビュー原理
•レビュー尺度
レビューにおける考慮事項
Copyright © 1994 Carnegie Mellon University4
レビューとは何か？ Review
レビューは自分自身の仕事を個人的に正当性・妥当性
・無欠陥性などを検証する方法である
レビューは以下の一連の検証手法の中の１つである
•インスペクション（精査）
•ウォークスルー（walk through）
•レビュー（厳しくチェック審査）
これらの全てが開発プロセスの早期に製品の欠陥1を
発見し、修理するという目的を持っている
1/ 欠陥（defects）とは誤りで、故障（failure）を引き起
こす原因となる
Copyright © 1994 Carnegie Mellon University5
インスペクション
インスペクションは1976年にIBMのFaganによって導入
された
インスペクションは構造化されたプロセスに従って行わ
れる
•同僚同士で成し遂げる
•管理者は参加しない
•各参加者の役割を明確にする
•準備が要求される
•目的は問題の発見である（“見逃し欠陥の摘出“）
インスペクションは要求、設計、コード、テストケース、 計
画、などに有用
Copyright © 1994 Carnegie Mellon University6
ウォークスルー
ウォークスルーは典型的には会議形式で実施される
•開発者が製品／成果物全体を通して参加者をリード
•参加者は同僚、マネージャー、又は他の興味を持つ
グループを含んでよい
•目的は話し合いまたは承認を得ること
•準備は不要
ウォークスルーは要求およびシステム設計問題に最も
有用である
Copyright © 1994 Carnegie Mellon University7
インスペクションとウォークスルー
資料事前配布・役割分担する
上司不参加
精査し欠陥摘出する
実装他の精査
準備不要
会議で説明（開発者先導）
納得を得る
要求仕様・設計仕様のチェック
Copyright © 1994 Carnegie Mellon University8
インスペクションのチェックポイント
全般
プログラム１つづつチェッ
ク
完全性
コードは設計を網羅してい
るか
include
完全か
初期化
変数、引数、
の原因
Copyright © 1994 Carnegie Mellon University9
呼び出し
関数呼び出しの引数
、ポインタ、＆使用法
名前
つづり、使用法
無矛盾、宣言範囲、
ポインタ
・初期化ヌル
・newの後delete
・newポインタは使
用後delete
遵守（じゅんしゅ）
標準
Copyright © 1994 Carnegie Mellon University10
レビュー
個人レビューでは
•担当者は個人的に自分達の製品／成果物をレビュー
する
•目的は最初のコンパイルやテストの前に欠陥を発見
すること。設計、実装の工程実施
•レビューは，構造化し測定すれば、最も効果的である
レビューは要求、設計、およびコードに対して使うことが
出来る
Copyright © 1994 Carnegie Mellon University11
なぜレビューをするのか- 1
レビューで欠陥を発見する方がテストでするよりもはるか
に効率が良いことをデータは示している
単体テスト方法とレビュー方法の比較
・単体テストでは、通常1時間当り約2~4個の欠陥しか
見つからない。
•コードレビューでは通常1時間当り約10個を発見する
•経験のあるレビュー者は製品中の欠陥の発見率は70
％以上。
•単体テストでは発見率が５０％を超えることは殆どない
レビューは単体テスト工程での時間当たり欠陥発見数の
2~5倍、発見できる（根拠：ＰＳＰデータ）
Copyright © 1994 Carnegie Mellon University12
Defect Removal Rates - 12
Students
Compile
25
Defects/Hour
20
15
Code Review
10
5
Unit Test
0
1
2
3
4
5
6
7
8
9
10
Program Numbe r
Copyright © 1994 Carnegie Mellon University13
なぜレビューをするのか -2
単体テスト後は、欠陥除去の費用はずっと高くなる
•統合とシステムテストでは欠陥の発見と修正に1件当
たり10~40人時がかかる
•インスペクションは通常欠陥当り1時間以内で済む
インスペクションデータの例
•O’Neilのデータ：欠陥当り25分で欠陥除去率が
80~90%
•Philipsのデータ：欠陥当り15分に対しテストでは
8時間になる
Copyright © 1994 Carnegie Mellon University14
なぜレビューをするのか-3
出来る限り早期に欠陥を除去する理由は
•レビュー、インスペクション、コンパイル、およびテスト
はそれぞれ欠陥の1部だけを発見する
•したがって、あるフェーズに入るコードがクリーン（無
欠陥）で ある程、出口でよりクリーンになるであろう
早期の欠陥除去は時間と金を節約する
•欠陥は開発プロセスの中で遅くなるほど発見と修理
に多くの金がかかる
•欠陥は開発完了後では、その発見と修正に、より多
くのコストがかかる
Copyright © 1994 Carnegie Mellon University15
なぜレビューは効率的か - 1
テストにおいては
•問題となる現象からスタートする
•そこでバグを見つけなければならない
•次に、原因を見つけ修正を工夫する
•最後に修正を組み込み、そのテストを行う
レビューとインスペクションだと
•欠陥が目に入る
•そこで、修正を工夫する
•最後に修正を組み込み、そのレビューを行う
Copyright © 1994 Carnegie Mellon University16
なぜレビューは効率的か - 2
テストにおいてシステムが異常な結果を出した場合、以下
のことを実施しなければならない
•異常を検出する
•そのときテストプログラムが何をしていたかを明らかに
する
•異常はプログラムの中のどこで起きたかを見つける
•どんな欠陥がそのような現象を引き起こしうるかを解明
する
計画も予定もしていなかった問題を探索することになる
それでは多くの時間がかかる
Copyright © 1994 Carnegie Mellon University17
なぜレビューは効率的か - 3
レビューやインスペクションだと
•自らのロジックを追いかける
•欠陥を見つけたとき自分がどういう状況にいるかが
明確にわかる
•そのプログラムが何をすべきで何をしなかったかを
知る
•だから，なぜこれが欠陥であるかがわかる
•よって，完全で効果的な修正を考案するうえで、より
良いポジションにいることになる
Copyright © 1994 Carnegie Mellon University18
PSP のレビュー戦略
ＰＳＰの目的は全てのプロセスフェーズでプログラムの
品質を可能な限り高めることである
これを達成するレビュー戦略として
•レビューに関するデータを集める
•それらのデータを研究する
•どういう作業が自分にとってベストかを決める
•自分の作業プロセスをそれに従って調整する
これが，自分自身の仕事のデータを活用して継続的に
学ぶプロセス，というものである
Copyright © 1994 Carnegie Mellon University19
レビューの基本原則
PSP レビューは以下の項目をもつ規範プロセスに従う
•開始及び終了の基準
•レビューの構造
•ガイドライン、チェックリスト、標準
ＰＳＰレビューの目標は、最初のコンパイル、またはテスト
前にあらゆる欠陥を発見することにおくことを提案する
この目標の達成に向かうには
•コーディング標準を使うべきである
•設計完了基準を使うべきである
•レビュープロセスを計測し改善するべきである
Copyright © 1994 Carnegie Mellon University20
０
目的
ガイドライン
１
開始条件
設計・プログラミン
グ完了
２
レビュ
コードレビューチェッ
クリスト
３
修正
４
チェック
５
終了条件
全ての欠陥修正、
欠陥ログ（欠陥型、
作り込み工程、除
去工程、修正時間
各修正の正当性を
チェック、全設計変
更を再レビュ、全修
正欠陥を新欠陥と
してログ、
十分レビューした
Copyright © 1994 Carnegie Mellon University21
レビューガイドラインとチェックリスト
全般事
項
完全性
インクル 初期化
ード
１プログ
ラムづ
づチェッ
ク
コードが 完全か
設計す
べてカ
バーし
ている
か
プログラ
ム、ル
ープ、関
数の開
始点
呼び出
し
関数呼
び出し、
ポインタ
、引数、
＆
Copyright © 1994 Carnegie Mellon University22
名前
文字列
ポインタ 出力書
式
ペア
スペル
と使い
方
ポインタ
で同定
、ヌルで
終了
ヌルで
初期化
、
Newの
後のみ
削除
｛｝が適
切か
行の段
落づけ
、空白
が適切
か
Copyright © 1994 Carnegie Mellon University23
論理
演算
行ごと コーディ ファイル
チェッ ング標 のオープ
ク
準
ン、クロー
ズ
演算
子、論
理関
係で()
準拠
各行
のチェ
ック：
区切り
記号
宣言、
オープン、
クローズ
Copyright © 1994 Carnegie Mellon University24
設計レビューの基本
１．レビューが可能な設計をする
２．明示されたレビュー戦略に従う
３．段階的に設計をレビューする
４．ロジックが要求を正しく実現していることを検証する
Copyright © 1994 Carnegie Mellon University25
欠陥型
文書
構
文
パ
ッ
ケ
ッ
ー
ジ
ア
サ
イ
ン
イ
ン
タ
フェ
ー
ス
チ
ェ
っ
キ
ン
グ
デ
ー
タ
機能
システ
ム
環境
コメント
綴
り
区
切
り
版
管
理
宣
言
、
名
前
呼
び
出
し
参
照
エ
ラ
ー
メ
ッ
セ
ジ
構
造
論理
、ポ
イン
タ
構成
工程
Copyright © 1994 Carnegie Mellon University26
１．レビューが可能な設計をする
レビューが可能な設計は
• 文脈（context）が定義されている
•精密に表現されている
•矛盾のないクリアな構造をもっている
これは次のようなことを示唆している
•設計の目的と機能が明示されている
•設計完了に対する判断基準をもっている
•設計が論理的要素で構成されている
Copyright © 1994 Carnegie Mellon University27
２．レビュー戦略に従う
レビュー戦略は、設計要素をレビューする順序を与える。
•これは製品の構造に依存する
•よってレビュー戦略は設計中は熟慮されているべきで
ある
レビュー戦略の目的は以下のような設計を創り出すこと
•段階的にレビューできる設計
•段階的にテストできる設計
•段階的にインテグレーションできる設計
Copyright © 1994 Carnegie Mellon University28
３．段階的な設計レビューを行う
段階的なレビューによって、全ての選択されたレビュー
項目が、注意深くチェックされることを確実にする
推奨するレビューの段階は以下である
1. 全ての設計要素が設計されたかチェックする
2. 全体的なプログラム構造とフローを検証する
3. 論理的な構成物の正当性をチェックする
4. 堅牢性（robustness）をチェックする
5. 適切な使用をしている事を確認するため、関数、
メソッド、プロシージャの呼び出しをチェックする
6. 特別な変数、パラメータ、 タイプ、ファイルが適切
に使用されてかをチェックする
Copyright © 1994 Carnegie Mellon University29
４．ロジックが正しく要求を実現してい
ることを検証する
要求された機能それぞれが設計によって言及されてい
ることを確認するため、要求項目をレビューする
見落としとか設計漏れがないか注意深くチェックする
Copyright © 1994 Carnegie Mellon University30
レビューの尺度（metrics）
明示的尺度
•レビュー対象のプログラムサイズｓ
•レビューに要した時間ｔ
•発見した欠陥の数Df
•見逃した欠陥の数Dm
派生的尺度
•レビューによる欠陥摘出率Df : %
Df ＝１００x(コンパイル前の除去欠陥）/(コンパイル前
の作り込み欠陥)
•時間当たりレビューした LOC
•KLOC 当たり発見した欠陥
•レビュー時間当たり発見した欠陥
•レビューの効果(review leverage)
Copyright © 1994 Carnegie Mellon University31
レビューによる欠陥摘出率 - 1
欠陥摘出率
•プロセスの品質の尺度
•レビューで発見された欠陥のパーセンテージ
•あるプロセスステップの有効性を測定する尺度
-設計レビューとコードレビューのステップ
-テスト前までのプロセス全体
-テストを含む開発プロセス
欠陥摘出率 (あるフェーズ、もしくは全体プロセスでの)
＝100*(発見した欠陥)／(発見した欠陥+見逃した欠陥)
Copyright © 1994 Carnegie Mellon University32
情報システム関係の仕事の中枢
製品出荷判定
欠陥摘出率がδ以下なら出荷、そうでなければ手戻り
手戻りを最小化する方策
Copyright © 1994 Carnegie Mellon University33
レビューによる欠陥摘出率 - 2
欠陥摘出率はテストや製品の使用を通じて全ての欠陥
が発見されてから計算する
全て、もしくは大半の欠陥がカウントされていれば、欠陥
摘出率はプロセスの早い時期から役に立つ
•設計レビューやコードレビューでの欠陥
•コンパイル時の欠陥
•単体テストでの欠陥
プロセスデータを使って制御パラメータを制御すること
により，欠陥摘出率の高いレビューを確実にすること
ができる
Copyright © 1994 Carnegie Mellon University34
欠陥除去影響力
( DRL: Defect Removal Leverage )
ＤＲＬは欠陥除去について、それぞれのプロセス・
ステップの相対的な有効性を計測したもの。
ＤＲＬは，あるプロセスステップにおいて単位時間
あたりに除去された欠陥の，基準プロセスのそれ
に対する比である
•通常基準は，単体テストである
•ＤＲＬ（X/UT）とは単体テスト(UT)と比べたときの
フェーズＸのＤＲＬである
•ＤＲＬは次のようにして算出される
欠陥除去影響力(X/UT)＝ 欠陥／時間（フェーズ X）
欠陥／時間（単体テスト）
Copyright © 1994 Carnegie Mellon University35
各種の欠陥除去影響力
DRL(D/UT)=（欠陥数/工程Dの時間）/（欠陥数/工程UTの時間
）
DRL(I/UT)
DRL（C/UT)
DRL（B/UT)
設
計
実装
I
コン
パ
イル
D
単体
デバッグ
単体
テスト
B
UT
運用
OP
C
Copyright © 1994 Carnegie Mellon University36
プロセス制御
プロセスを制御するためにはそのプロセスを実行中で
も使える尺度が必要である
欠陥摘出率と欠陥除去影響力（ＤＲＬ）は強力な指標で
あるが、プロセスが完了するまで使えない
必要な尺度：
•欠陥摘出率と相関のある指標
•開発の途中で使える指標
Copyright © 1994 Carnegie Mellon University37
潜在的制御パラメータ
欠陥摘出率に対する潜在的制御パラメータとして次の
ようなものがある
•時間あたりレビューされた ＬＯＣ (LOC/Hour)
•時間あたり発見した欠陥 (Defects/Hour)
•ＫＬＯＣあたりに発見した欠陥 (Defects/KLOC)
PSPの研究で欠陥摘出率について次のような相関を
発見した
•LOC/Hour:
-0.63＜有意水準＜ 0.005
•Defects/Hour:
0.14＜有意水準 ＜ 0.25
•Defects/KLOC: 0.47＜有意水準＜ 0.01
その結果が偶然に得られ得る確率
良いものはないが、この中ではLOC/Hourがベスト
Copyright © 1994 Carnegie Mellon University38
Yield vs. LOC/Hour - Student 12
Yield - % of Early Removal
Defects
80
70
60
50
40
30
20
10
0
0
200
400
600
LOC/Hour
Copyright © 1994 Carnegie Mellon University39
Yield - % of Early Removal
Defects
Yield vs LOC/Hour - Student 20
100
90
80
70
60
50
40
30
20
10
0
0
100
200
300
400
LOC/Hour
Copyright © 1994 Carnegie Mellon University40
単位時間当たりレビューしたLOC
学生のデータはかなり変動している
これら例では、構造化されたレビューが以下の条件の
時に効果的といえることを示している
•定義された手順によって行われていること
•チェックリストをつかっていること
•それぞれのエンジニアの欠陥に対する経験に合わ
せてあること
PSPに対し制御目標としては、時間あたり２００ＬＯＣ以
上のレビューをしないことを提案する
Copyright © 1994 Carnegie Mellon University41
レビューについての考察
チェックリスト
コンパイル前後のレビュー
レビューとインスペクションの関係
Copyright © 1994 Carnegie Mellon University42
チェックリスト
精密に仕事を実行しようとすとき、１度に１つ以上の仕
事をすることは難しい
チェックリストはレビューを実行するときのレビュー
ステップの提案順序を定義する
それぞれのアイテムにチェックマークをつけていけば、
レビューを適切に実行できる可能性が高い
それぞれの経験に合った、個人用のチェックリストを作
るのがよい
Copyright © 1994 Carnegie Mellon University43
コンパイル前のレビュー １
PSPは最初のコンパイルの前にレビューすることを
求める
理由は
•レビュー時間はコンパイルの前でも後でもおよそ同じ
だけかかる
•コードレビューはコンパイラーが見逃すシンタックスの
欠陥をも発見する
•コンパイル済みコードのコードレビューは効果が大変
少なくなる傾向にある
•コンパイラーはレビューの前でも後でも同じくらい
効果的である
Copyright © 1994 Carnegie Mellon University44
Compile vs Test Defects Student 20
10
Test Defects
8
6
4
2
0
0
10
20
30
40
50
Compile Defects
Copyright © 1994 Carnegie Mellon University45
Compile vs Test Defects Student 1
10
Test Defects
8
6
4
2
0
0
5
10
15
20
Compile Defects
Copyright © 1994 Carnegie Mellon University46
コンパイル前のレビュー
２
PSPはコンパイルをレビューの品質のチェックに使う
•コンパイルであまりに多くの欠陥が見つかった場合は
もう一度レビューすることが求められる
•コンパイルで欠陥が無い場合は、大半の欠陥は既に
見つかったと思って良い
PSPの全演習を完了後、コンパイルの前と後のレビュ
ーデータを集めて，どちらのレビューが自分にとって最
も役に立つかを調べてみよ
Copyright © 1994 Carnegie Mellon University47
レビューとインスペクション
インスペクションの基本的な狙いは、見逃している要求上
と設計上の問題を摘出することに置くべきである
プログラムに単純な欠陥が沢山ある場合、インスペクター
は集中力を欠き、より大きな問題をしばしば見逃してしま
う
最初にコードレビューする（ｲﾝｽﾍﾟｸｼｮﾝ前に自分でﾚﾋﾞｭｰし
ておく）ことは
•インスペクションに高品質プロダクトを提出する
•インスペクターの時間に対する敬意を示す
•より高品質のインスペクションを可能にする
Copyright © 1994 Carnegie Mellon University48
課題＃７
テキストの８章を読んでレポートＲ４を作りなさい
レポートに対する要求事項として付録Ｄをチェックしなさい
この課題は以下のことを求めています
•Ｒ４レポートを作成するプロセスの設計
•このプロセスの中には計画と事後分析のフェーズを
含める
•レポートＲ４の計画を立てる
•レポートを作る
•このレポート，設計したプロセス、集めたプロセスデータ
を提出する
Copyright © 1994 Carnegie Mellon University49
課題演習 Ｒ４レポート作成
・まずプロセスを定義せよ。そのプロセスを使ってＲ４を
作成せよ（後日Ｒ４を更新する）。
・レビュー（設計とコード）のチェックリストを作成せよ。
・タスク1：データ分析と6つのプログラム（1A－６A）の
レポートを作成するためのプロセスを開発せよ。そのプ
ロセスが含むべき工程は計画工程、タスク実施工程、
事後分析工程。プロセス記述とプロセス稼動計画書を
提出せよ。
・タスク2：上記を稼動。計画書に計画時間を記入し、実
績時間を追記せよ。
・タスク3：プログラム１A－６Aのデータを分析せよ（注
意点は次頁参照）。
Copyright © 1994 Carnegie Mellon University50
プログラム１A
ソースプログラムを読み、行数をカウントして表示する。
プログラム2A
１セットのデータの平均値、標準偏差を求め表示する。
言語：プログラミング Java、C++、その他（擬似英語）
設計：図式言語、UML、BPMN、その他
Copyright © 1994 Carnegie Mellon University51
課題演習 続
分析問題
・LOCと開発時間の見積もりの正確さ（開発進展を分
析せよ）
・プログラムで作り込まれたり除去された欠陥型の分
析（付表D23を作成せよ）
・コンパイル時発見の欠陥型の分析（付表D24）
・R3レポート（付表D22）を見て欠陥修正時間を分析
・設計レビューで最も頻発する設計欠陥を見つけよ（設
計チェックリスト活用）
・コードレビューについても上記を行え
Copyright © 1994 Carnegie Mellon University52
講義７のまとめ
設計レビュー及びコードレビューは次に対し効果をもつ
•プログラムの品質を改善する
•開発時間を短縮する
効果的なレビューをするために、次のことを行う
•レビューのゴールを確立
•レビュープロセスの規範に従う
•レビューの品質を計測し改善する
Copyright © 1994 Carnegie Mellon University53