デザインレビュー

設計の各段階で、設計書などの成果物を関係者が評価し、要件を満たしているか、問題がないかを確かめるレビュー。設計の段階で欠陥を見つけて取り除くことで、後の工程での手戻りを減らす。DRと略す。

設計の各段階の成果物を、関係する部門や専門家が集まって評価し、要求事項を満たしているか、問題がないかを確かめるレビュー。次の段階に進む前に設計上の誤りや考慮漏れを見つけ、後の工程での手戻りを防ぐ。

設計の妥当性を関係者が確認する会議。DRともいい、工程の節目で実施して後戻りを防ぐ。

設計の各段階の成果物を、関係する部門や専門家が集まって評価し、要求事項を満たしているか、問題がないかを確かめるレビュー。次の段階に進む前に設計上の誤りや考慮漏れを見つけ、後の工程での手戻りを防ぐ。

同じ立場や同程度の技術をもつ同僚どうしで成果物を確認し合うレビュー。上司や顧客を交えないため率直に指摘しやすく、設計書やソースコードの誤りの早期発見と知識の共有に役立つ。

システム設計の妥当性、完全性、整合性を検証するための公式なレビュー活動。基本設計、詳細設計の各段階で実施され、要件との適合性や設計上の問題点を早期に発見する。監査ではレビュー記録の確認を行う。

システム監査基準の基準の1つで、監査人が、監査を依頼する経営者などのニーズを把握して監査の目的や範囲を定め、監査の品質を確保するための体制を整えることを求めるもの。システム監査の多くは法律で義務づけられていない任意監査であるため、ニーズに合った監査を行うことと、監査の手続や結果の品質を管理・評価する仕組みが重要になる。

システムの設計段階で、守るべき資産、データの流れ、信頼境界を整理し、想定される脅威とその対策を体系的に洗い出す手法。なりすまし、改ざん、否認、情報漏えい、サービス妨害、権限昇格の6分類で脅威を考えるSTRIDEなどを用い、セキュリティバイデザインを実践する手段となる。

作成したソースコードを作成者以外が読み、誤り、コーディング標準への違反、保守性や性能・セキュリティ上の問題を指摘する活動。プルリクエストを使ったレビューのほか、インスペクションやウォークスルーの形で行う。

モデレータが主導し、あらかじめ役割と確認項目を決めて成果物を検査する公式のレビュー手法。参加者は事前に成果物を読み込み、会議で欠陥を洗い出して記録し、修正の完了まで追跡する。レビューの中で最も厳格に行われる。