IEEE1028で定義されているように、レビューとは、ソフトウェア要素やプロジェクトの状態を評価し、それが計画された結果に沿っているかどうかを判断し、改善を可能にするための手段です。
- 狭義の「ソフトウェア・レビュー」は、通常、ソフトウェアの文書やソース・プログラムのレビューを指します。
- 広義には、「ソフトウェア・レビュー」には、ソフトウェア・テストやマネジメント・レビューに付随するレビューも含まれます。
ソフトウェアレビューには、ソフトウェア要件レビュー、概要設計レビュー、詳細設計レビュー、ソフトウェア検証・妥当性確認レビュー、機能チェック、物理チェック、総合チェック、管理レビューが含まれます。
ソフトウェア要件レビュー。ソフトウェア要求仕様で指定された要求が適切であることを確認するために、ソフトウェア要求分析の最後にソフトウェア要求レビューを実施する必要があります。
概要設計レビューアウトライン・デザイン・レビューは、ソフトウェア・アウトライン・デザインの最後に実施し、全体構造、外部インターフェイス、主要コンポーネントへの機能割り当て、グローバル・データ構造、主要コンポーネント間のインターフェイスの観点から、ソフトウェア設計仕様に記述されたソフトウェア・アウトライン・デザインの適切性を評価する必要があります。
詳細設計レビュー。詳細設計レビューは、ソフトウェアの詳細設計の最後に実施され、ソフトウェア設計仕様に記述されたソフトウェアの詳細設計が、各基本コンポーネントの機能的、アルゴリズム的、プロセス的な記述の観点から適切であるかを評価する必要があります。
ソフトウェア検証および妥当性確認レビュー。ソフトウェア検証及び妥当性確認計画の完了後、ソフトウェア検証及び妥当性確認計画に規定された検証及び妥当性確認方法の適切性及び完全性を評価するために、ソフトウェア検証及び妥当性確認レビューを実施しなければなりません。
機能チェック。ソフトウェアのリリースに先立ち、開発されたソフトウェアがソフトウェア要求仕様で指定されたすべての要件を満たしていることを検証するために機能チェックを行います。
物理的検査。ソフトウェアの検収に先立ち、物理的な検査を行い、手順と文書が揃い、納品できる状態になっていることを確認します。
包括的なチェック。ソフトウェアの受入れ時に、コードと設計文書の整合性、インタフェース仕様の整合性、設計実装と機能要件の整合性、機能要件とテスト記述の整合性を検証するために、ユーザーまたはユーザーから委託された専門家が、受入れ対象のソフトウェアの設計のサンプルを総合的にチェックすることが許可されていること。
マネジメントレビュープログラムの実施に関する定期的なマネジメントレビューを実施し、レビューの対象となる部門から独立した機関または認定された第三者の支援の下で実施しなければなりません。
審査の過程では、以下の点に留意する必要があります：
テストをレビューの代用とすべきではありません。欠陥の多くは初期段階で発見され、発見が遅れれば遅れるほど、その修正にかかるコストは高くなります。また、次のステップに進む欠陥は、次のステップで複数の欠陥を引き起こす可能性があり、排除コストが飛躍的に増加します。初期の段階では、レビューはできますが、テストはできません。レビューの目的は、テスト段階に漏れる欠陥の数を減らすことです。レビューには多くの時間がかかりますが、テストにかかる時間は節約できます。また、テストでは特定のタイプの欠陥は検出できません。
レビュアーは本質的な問題に焦点を当てるべきです。レビュアーが、製品のデザインよりも、文書の書式や文言など、本質的でない問題に焦点を当てすぎてしまうことがよくあります。その理由として考えられるのは、適切な人材がレビューに参加していないこと、レビュー担当者がレビュー対象について十分な知識がなく、より深い問題を特定できないことです。
認証評価会議を問題解決セミナーに変身させてはなりません。審査会の主目的は問題発見であり、問題解決ではなく、問題解決は審査会後に行うべきものです。しかし、開発者の技術追求のあまり、審査会が問題解決セミナーと化してしまい、審査会の多くの時間を奪い、その結果、多くの審査内容が無視され、数え切れないほどの隠れた危険が残されています。
レビューはプロジェクト計画に組み込むべきレビューに参加するには、多大な時間と労力を投資しなければなりません。しかし、現実には、レビューがその場しのぎになってしまうことがよくあります。このように、レビュアーがレビュー対象を理解していないケースがあるのは当然です。
レビュー参加者は、レビュープロセス全体を理解する必要があります。レビュー参加者がレビューのプロセス全体を理解していなければ、当然抵抗が生じます。なぜなら、このようなことをすることの効果が見えず、非常に混乱した気分になり、レビューへの参加意欲に深刻な影響を与えるからです。
レビュアーは、事前にレビュー資料を十分に理解しておく必要があります。どんなレビュー資料も他人の知恵と努力の結晶であり、十分な時間をかけて理解し、慣れ親しみ、考えることが必要です。そうすることでしか、貴重な根深い問題をレビュー会議で発見することはできません。多くのレビューでは、レビュアーが様々な理由で、レビュー会議でのレビュー資料に対する理解が十分でないために、レビュー会議が奇妙な現象の技術報告になってしまいます。
注意すべきは、審査の組織です。認定を組織化する過程で、多くの人は細部にあまり注意を払いません。例えば、会議の時間の設定、会議の通知、会議場所の選択、会場環境のレイアウト、会議設備の提供、会議の雰囲気の調整と制御などですが、実際にはこのような細部が認定会議の効果に大きく影響します。
