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 De fe ct Re m oval Rate s - 12 Stude nts Compile 25 Defects/Hour 20 15 Code Review 10 5 Unit Test 0 1 2 3 4 5 6 7 8 9 10 Pro g ram Numb er 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 Yie ld vs . LOC/Hour - St ude nt 12 Yield - % of Early Removal Defects 80 70 60 50 40 30 20 10 0 0 200 400 600 L OC/Ho u r Copyright © 1994 Carnegie Mellon University39 Yield - % of Early Removal Defects Yie ld vs LOC/Hour - St ude nt 20 100 90 80 70 60 50 40 30 20 10 0 0 100 200 300 400 L OC/Ho u r 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 Com pile vs Tes t De fe cts Stude nt 20 10 Test Defects 8 6 4 2 0 0 10 20 30 40 50 Co mp ile Defects Copyright © 1994 Carnegie Mellon University45 Com pile vs Tes t De fe cts Stude nt 1 10 Test Defects 8 6 4 2 0 0 5 10 15 20 Co mp ile 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
© Copyright 2024 ExpyDoc
