ソフトウェアレビュー

ソフトウェアレビューとは、「プロジェクト担当者、管理者、ユーザー、顧客、ユーザー代表、その他の関係者がソフトウェア製品を審査し、コメントや承認を得るプロセスまたは会議」です。^[1]

この文脈では、「ソフトウェア製品」という用語は、「ソフトウェア開発活動の成果物として作成された技術文書または部分文書」を意味し、契約書、プロジェクト計画および予算、要件文書、仕様、設計、ソース コード、ユーザー ドキュメント、サポートおよび保守ドキュメント、テスト計画、テスト仕様、標準、およびその他の種類の専門的な作業成果物などの文書が含まれる場合があります。

ソフトウェアのレビューは、次の 3 つのカテゴリに分けられます。

• ソフトウェアピアレビューは、著者の1人以上の同僚によって行われ、作品の技術的な内容や品質を評価します。^[2]
• ソフトウェア管理レビューは、管理担当者によって実施され、完了した作業の状態を評価し、下流の活動に関する決定を下します。
• ソフトウェア監査レビューは、ソフトウェア プロジェクトの外部の担当者によって実施され、仕様、標準、契約上の合意、またはその他の基準への準拠を評価します。

• コードレビューとは、コンピュータのソースコードを体系的に検査することです（多くの場合、ピアレビューと呼ばれます）。
• ペア プログラミングは、2 人が同じワークステーションで一緒にコードを開発するタイプのコード レビューです。
• 検査は、レビュー担当者が明確に定義されたプロセスに従って欠陥を見つける、非常に正式なタイプのピアレビューです。
• ウォークスルーはピアレビューの一種で、作成者が開発チームのメンバーやその他の関係者を率いてソフトウェア製品をレビューし、参加者が質問したり欠陥についてコメントしたりします。
• テクニカル レビューは、資格のある担当者のチームがソフトウェア製品が意図された用途に適しているかどうかを検査し、仕様や標準との相違点を特定するピア レビューの一種です。

「形式」とは、アクティビティが合意された（文書化された）ルールによってどの程度管理されているかを示します。ソフトウェアレビュープロセスは形式の範囲にわたって存在し、一方の端には「バディチェック」などの比較的構造化されていないアクティビティがあり、もう一方の端にはウォークスルー、テクニカルレビュー、ソフトウェア検査などのより正式なアプローチがあります。IEEE Std. 1028-1997 は、最後の 3 つ（「正式なピアレビュー」）のそれぞれについて、正式な構造、役割、プロセスとソフトウェア監査を定義しています。^[1] IEEE 1028-1997 は IEEE 1028-2008 に引き継がれました。^[3]

調査研究^{[誰が? ]}では、費用対効果の点で公式レビューの方が非公式レビューよりはるかに優れているという結論を支持する傾向があります。非公式レビューは、多くの場合、不必要に高価になる可能性があり (焦点が定まっていないために時間が浪費されるため)、発見され修復される実際の欠陥の数が比較的少ないため、まったく不当な安心感を与えることがよくあります。

IEEE 1028 は、「正式な」レビュー (特にソフトウェア監査の場合、多少のバリエーションあり) の一般的な一連のアクティビティを定義します。この標準では、管理レビュー、技術レビュー、検査、ウォークスルー、監査などの区別が適用されます。

規定された標準的な活動の順序は、IBMでマイケル・フェイガンが最初に開発したソフトウェア検査プロセスに大きく基づいています。^[4]異なるタイプのレビューでは、さまざまな厳密さの度合いでこの構造が適用されますが、すべての活動は検査に必須です。

• 0. [エントリ評価]:レビューリーダーは、エントリ基準の標準チェックリストを使用して、レビューを成功させるための最適な条件が整っていることを確認します。
• 1. 管理の準備:責任ある管理者は、レビューに適切な人員、時間、資材、ツールが確保され、ポリシー、標準、その他の関連基準に従ってレビューが実施されるようにします。
• 2. レビューの計画:レビュー リーダーは、レビューの目的を特定または確認し、レビュー担当者のチームを編成し、レビューを実施するために必要なすべてのリソースがチームに備わっていることを確認します。
• 3. レビュー手順の概要:レビューリーダーまたはその他の資格のある人物は、(必要に応じて会議で) すべてのレビュー担当者がレビューの目的、レビュー手順、利用可能な資料、およびレビューを実施するための手順を理解していることを確認します。
• 4. [個人] 準備:レビュー担当者は、レビュー対象の作業のグループ審査に向けて、個別に「異常」(潜在的な欠陥) がないか注意深く検査する準備をします。異常の性質は、レビューの種類と目的によって異なります。
• 5. [グループ] 検討:レビュー担当者は予定された時間に集まり、準備活動の結果をまとめ、レビュー対象の文書 (または活動) のステータスに関する合意に達します。
• 6. 再作業/フォローアップ:作業成果物の作成者 (または他の担当者) は、欠陥を修復したり、検査会議で合意された要件を満たしたりするために必要なあらゆるアクションを実行します。レビュー リーダーは、すべてのアクション項目が完了したことを確認します。
• 7. [終了評価]:レビューリーダーは、レビューを成功させるために必要なすべてのアクティビティが完了し、レビューの種類に適したすべての出力が完了したことを確認します。

ソフトウェア レビュー (特に正式なレビュー) の最も明らかな価値は、テストや現場での使用 (「欠陥検出プロセス」) で問題が特定されるよりも早く、より安価に問題を特定できることです^{[引用が必要]}。適切に実施されたレビューによって欠陥を見つけて修正するコストは、同じ欠陥がテスト実行や現場で見つかった場合よりも 1 桁または 2 桁少なくなる可能性があります。^{[引用が必要]}

ソフトウェア レビューの 2 番目で、究極的にはより重要な価値は、欠陥の極めて少ないドキュメントの開発について技術作成者をトレーニングするために使用できること、また、欠陥を助長するプロセスの不備を特定して除去するために使用できることです (「欠陥防止プロセス」)。

これは特に、作業が完了するまで待つのではなく、作業サンプルに対して早期かつ頻繁にピアレビューを実施する場合に当てはまります。小規模な作業サンプルを早期かつ頻繁にレビューすることで、著者の作業プロセスにおける体系的なエラーを特定し、さらに欠陥のある作業が行われる前に修正することができます。著者のスキルが向上すると、高品質の技術文書の作成にかかる時間が大幅に短縮され、下流のプロセスで文書を使用する際のエラー率が大幅に低下します。

一般的な原則として、技術文書が早期に作成されるほど、その欠陥が下流の活動とその成果物に与える影響は大きくなります。したがって、マーケティング計画、契約、プロジェクト計画とスケジュール、要件仕様などの文書を早期にレビューすることで、最大の価値が得られます。研究者と実務家は、バグやセキュリティの問題を見つけるためのレビュープロセスの有効性を実証しています。^[5]

• ソフトウェアの品質
• ソフトウェア開発哲学のリスト