このページでは、承認レビューと成果物レビュー、ウォークスルー・インスペクション・ラウンドロビンなどの手法、デザインレビューのポイント、形式手法がわかります。
- 一言で言うと：
- 設計書やプログラムなどの成果物を、人の目で確かめて、早いうちに問題を見つける話
- 「誰が進行役をするか」で、レビューの手法が分かれる
レビューの種類（承認レビュー・成果物レビュー、IV&V）→ 代表的な手法（ウォークスルー、インスペクションなど）→ 設計書のレビュー（デザインレビュー）→ 数学で確かめる（形式手法）
覚え方の軸
- レビューの目的は2つ
- 承認レビューは、次の工程に進むための関門
- 成果物レビューは、問題を早く見つけて品質を上げる、要求を満たしているかを確かめる
- ピアレビューの手法は「誰が仕切るか、集まるか」で分ける
- 作成者が説明して進めるのが、ウォークスルー
- 作成者以外のモデレータが仕切るのが、インスペクション
- 持ち回りで責任者をするのが、ラウンドロビン
- 集まらずに個別に見てもらうのが、パスアラウンド
- 上流のミスほど、直すのが高くつく
- だから、レビューで早く見つけることが大事
レビューの種類と代表的なレビュー手法（★）
- レビュー：
- 各種設計書やプログラムソースなどの成果物の、問題点や曖昧な点、成果物としての妥当性を検証すること
- レビューが大事な理由：
- システムへの要求仕様は、開発の各工程で少しずつ詳しくなっていくので、設計上のミスはできるだけ早く見つける必要がある
- 上流工程の設計ミスが見つからずに、下流のプログラミングやテストまで引き継がれると、直すコストは、プログラムのミスを直すコストに比べて莫大になる
- そこで、エラーを早く見つけるのに有効な手段の1つがレビュー
- また、IV&Vをプロジェクトの早い工程から取り入れると、より大きな効果が得られる
- レビューの例え：
- 家の設計図の段階で「窓が足りない」と気づけば、線を1本足すだけで済む。家を建ててから気づくと、壁を壊す工事になる
① レビューの種類
| 種類 | 目的 |
|---|---|
| 承認レビュー | 成果物の内容を審査して、次の工程に進むための関門として行う |
| 成果物レビュー | 成果物の問題点を早く見つけて品質を上げること、また、成果物が要求事項を満たしているかの確認（遵守度合いの検査）を目的に行う |
- IV&V（Independent Verification and Validation：独立検証及び妥当性確認）：
- 開発チームとは独立した組織が、検証と妥当性確認（遵守度合いの検査）を行うこと
- 開発チームとIV&V組織が同じタイミングでレビューをし、IV&V組織が問題を見つけたら、開発チームに報告して解決方法を話し合う
- 例えば、自分で書いた作文を、別のクラスの先生にも同時に読んでもらう
② 代表的なレビュー手法（ピアレビュー）
- ピアレビュー：
- 一般にソフトウェアのレビューといえば、同じプロジェクトの同僚や専門家仲間と行うピアレビューを指す
- 代表的な手法は、ウォークスルー、インスペクション、ラウンドロビンのレビューなど
| 手法 | 進行役 | 特徴 |
|---|---|---|
| ウォークスルー | 成果物の作成者が説明者 | 作成者とその関係者で行う。参加者は対等 |
| インスペクション | 作成者以外のモデレータ | 役割を事前に決め、チェックシートで焦点を絞って迅速に評価する |
| ラウンドロビン | 参加者が持ち回りで責任者 | 全員が責任者を務めるので、参画意欲が高まる |
| パスアラウンド | （集まらない） | 成果物を複数のレビューアに個別に見てもらう |
ウォークスルー
- ウォークスルー：
- レビュー対象物の作成者が説明者になって行うレビュー
- 成果物の作成者と、その関係者で行う
- ウォークスルーが生まれた理由：
- 従来のミーティング形式のレビューには、「成果物の品質評価が作成者の評価になりやすい」「だらだらと長時間になりやすい」という欠点があった
- それをなくしたのがウォークスルー
- プログラムのウォークスルー：
- プログラマが主催し、複数の関係者が集まって、プログラムリストを追跡してエラーを探す
- 入力を仮定してソースコードを追跡するように、ステップごとに手順をシミュレーションしてレビューする
- ウォークスルーの特徴：
- 作成者が内容を順に説明し、参加者は説明に沿って対象物を追跡・検証して、不明点や問題点を指摘する
- 参加者はお互いに対等な関係
- 見つかったエラーの修正は作成者に任される
- 修正作業は検討テーマにしない（その場では直し方を話し合わない）
- ウォークスルーの例え：
- 旅行の計画を立てた人が、「朝8時に駅に着いて、この電車に乗って…」と順に説明し、みんなで「その乗り換えは間に合う？」と指摘する
インスペクション
- インスペクション：
- 作業成果物の作成者以外の参加者が、モデレータとして会議の進行を仕切って行うレビュー
- あらかじめ参加者の役割を決めておき、レビューの焦点を絞って迅速に評価する
- モデレータ：
- レビューを主導し、参加者にそれぞれの役割を果たさせるようにする人
- コードインスペクション：
- ソースコードに対するインスペクション
- インスペクションの特徴：
- モデレータが進行を仕切り、事前に作ったチェックシートと照らし合わせて検証する
- 絞られた問題について、いろいろな角度から分析する
- 問題点は問題記録表に記録し、作成者に指摘して、問題点が処置されるまで追跡する
- レビューの心がけ：
- 作成者を非難しない。成果物の内容に焦点を当てて、課題や欠陥を指摘する
- インスペクションの例え：
- 車検。検査員（モデレータ）が、チェックリストに沿って決まった項目を手早く調べ、不合格の箇所は直るまで追いかける
ラウンドロビンのレビュー
- ラウンドロビンのレビュー：
- レビュー参加者が持ち回りでレビュー責任者を務めながら、全体としてレビューを進める技法
- 参加者全員が、それぞれの分担で責任者を務めるので、全員の参画意欲が高まる
- 例えば、会議の司会を毎回交代でやると、全員が当事者意識を持つ
パスアラウンド
- パスアラウンド：
- レビュー対象の成果物を、複数のレビューアに個別にレビューしてもらう方法
- パスアラウンドのやり方：
- 電子メールなどで、レビューアに配布する方式
- 複数のレビューアに、回覧形式で順番に見てもらう方式
- 一か所（掲示板など）で閲覧してもらう方式
- 例えば、回覧板。集まらずに、順番に目を通してもらう
③ デザインレビュー
- デザインレビュー：
- 検証する成果物が設計仕様書であるレビュー
- 外部設計、内部設計などの各設計工程で、その成果物である設計書を対象に、曖昧な点や問題点を見つけるために行う
- コードレビュー：
- デザインレビューが設計段階で設計書や仕様書を対象に行うのに対し、ソフトウェア構築段階でプログラム（ソースコード）を対象に行うレビュー
- 外部設計書のデザインレビューのポイント：
- ユーザが要求したシステム要件が定義されているか
- 外部設計書で定義した内容の実現可能性や妥当性
- 内部設計書のデザインレビューのポイント：
- 外部設計書との整合性。機能がもれなく設計されているか
- プログラム間インタフェースの誤りや、論理的矛盾はないか
- 設計書（ドキュメント）が標準に準拠しているか
- プログラム設計へ配慮された内部設計書になっているか
- 外部と内部の見分け方：
- 外部設計書は、「ユーザの要求」と照らし合わせる
- 内部設計書は、「外部設計書」と照らし合わせ、次の「プログラム設計」につながるかを見る
形式手法
- レビューの弱点：
- レビューでは、仕様に対する明確な検証基準がない
- 品質確保の程度が、レビュー担当者の能力に左右されることがある
- 形式手法：
- 論理学や離散数学を基礎とした形式的な仕様記述とモデル検証（形式検証）によって、品質を確保しようという手法
- 形式仕様記述言語：
- 明確で矛盾がない（数学的に正しいと証明される）仕様記述ができる言語
- これを使って、システムの仕様（状態、振舞い）を曖昧さのないモデルで表し、明確な検証基準のもとで検証する
- 代表的なモデル規範型形式仕様記述言語：
- VDM-SLや、それをオブジェクト指向に拡張したVDM++など
- 形式手法の例え：
- 「だいたい合っている」と人が目で確かめるのではなく、数学の証明のように「必ず正しい」と示す
混同しやすいペア
- 承認レビュー ／ 成果物レビュー
- 承認レビューは、次の工程に進むための関門
- 成果物レビューは、問題点を早く見つけて品質を上げる、要求を満たしているかを確かめる
- IV&V ／ ピアレビュー
- IV&Vは、開発チームと独立した組織が検証と妥当性確認を行う
- ピアレビューは、同じプロジェクトの同僚や専門家仲間と行う
- ウォークスルー ／ インスペクション
- ウォークスルーは、作成者が説明者。参加者は対等。修正は作成者に任せ、修正方法は話し合わない
- インスペクションは、作成者以外のモデレータが仕切る。役割を決め、チェックシートで検証し、処置されるまで追跡する
- ラウンドロビン ／ パスアラウンド
- ラウンドロビンは、持ち回りでレビュー責任者を務める。参画意欲が高まる
- パスアラウンドは、集まらずに、メールや回覧などで個別に見てもらう
- インスペクション ／ コードインスペクション
- インスペクションは、成果物全般が対象
- コードインスペクションは、ソースコードが対象
- デザインレビュー ／ コードレビュー
- デザインレビューは、設計段階で、設計書や仕様書が対象
- コードレビューは、ソフトウェア構築段階で、ソースコードが対象
- 外部設計書のデザインレビュー ／ 内部設計書のデザインレビュー
- 外部設計書は、ユーザの要求が定義されているか、実現可能で妥当か
- 内部設計書は、外部設計書と整合しているか、インタフェースの誤りや矛盾はないか、標準に準拠しているか
- レビュー ／ 形式手法
- レビューは、人が確かめる。明確な検証基準がなく、担当者の能力に左右される
- 形式手法は、数学に基づく形式仕様記述言語（VDM-SLなど）で、明確な基準のもとで検証する
- ウォークスルー（レビュー手法） ／ ウォークスルー法（システム監査技法）
- レビューのウォークスルーは、作成者が説明して、成果物を追跡・検証する
- 監査のウォークスルー法は、監査人がデータの流れとコントロールを、書面上や実際に追跡する