設計審査（米国政府）

米軍の統合調達ライフサイクル^{[1] [2]}では、技術部門に複数の調達「技術レビュー」があります。^[3]技術レビューと監査は調達を支援し、その数と種類は調達に合わせて調整されます。^[4]全体的なガイダンスは国防調達ガイドブックの第4章から流れ、^[5]ローカルな詳細はレビュー組織によってさらに定義されます。^{[6] [7] [8] [9]}検討される典型的なトピックには、プログラム/契約指標の妥当性、適切な人員配置、リスク、予算、スケジュールなどがあります。

NASAのエンジニアリング設計ライフサイクルでは、技術的およびプログラム的な説明責任を果たし、プロジェクトへの資金提供を承認するために設計レビューが行われます。 ^[10]設計レビューでは、分野の専門家と管理者の独立したチームによる詳細な評価が行われ、設計（またはコンセプト）がプログラム的および技術的な観点から現実的かつ達成可能であるかどうかが評価されます。

設計レビューは、米国食品医薬品局の規制規則 21CFR820 に記載されている設計管理システムの一部として、医療機器開発者にも義務付けられています。21CFR820.3(h) では、設計レビューは「設計要件の妥当性を評価し、設計がこれらの要件を満たす能力を評価し、問題を特定するための、文書化された包括的かつ体系的な設計検査」と説明されています。FDA は、設計レビューには独立したレビュー担当者を含める必要があることも規定しています。

取り組みによって行われるレビューのリストと、レビューで使用されるコンテンツ、性質、プロセス、および目的は、関係する組織と取り組みの特定の状況によって大きく異なります。たとえば、米国国防総省内であっても、システム要件レビューのケースには、(1) 個々の要件の 5 日間の精査、(2) システム要件が承認され、開発文書が正式なアクション アイテムとともにレビューされた後にのみ許可される開発計画文書の 2 日間の議論、(3) プロジェクト マネージャーによって決定された内容の半日のパワーポイント (出席者は高レベルの (非技術系の) 利害関係者に限定され、PM が「SRR 完了」を宣言できる以外に出力はありません) などがあります。

取り組みに関して行われる可能性のあるレビューには、次のようなものがあります。

MCR は、ミッションの必要性を確認し、提案されたミッションの目的とそれらの目的を達成するための概念を検討します。

SRR は、システムに対して定義された機能要件とパフォーマンス要件、および予備プログラムまたはプロジェクト計画を検査し、要件と選択されたコンセプトがミッションを満たすことを確認します。

MDR は、提案された要件、ミッション アーキテクチャ、およびミッションのすべての機能要素へのフローを検査して、全体的なコンセプトが完全で、実現可能であり、利用可能なリソースと一致していることを確認します。

SDRは、提案されたシステム アーキテクチャと設計、およびシステムのすべての機能要素へのフローを確認します。

PDRは、予備設計が許容可能なリスクとコストおよびスケジュールの制約内ですべてのシステム要件を満たしていることを実証し、詳細設計に進むための基礎を確立します。適切な設計オプションが選択され、インターフェースが特定され、検証方法が記述されていることを示します。^{[11] [12]}

PDR の一般的な目的は次のとおりです。

• すべてのシステム要件が検証され、割り当てられ、要件が完了し、フローダウンがシステムパフォーマンスを検証するのに適切であることを確認します。
• 提案された設計が機能要件と性能要件を満たすことが期待されることを示す
• 最終設計に進むために提案された設計アプローチが十分に成熟していることを示す
• 設計が検証可能であり、リスクが特定され、特徴付けられ、適切な場合に軽減されていることを示します。

CDRは、設計の成熟度が、本格的な製造、組み立て、統合、テストを進めるのに適切であることを示しています。CDRは、技術的努力が飛行および地上システムの開発とミッション運用を完了し、特定されたコストとスケジュールの制約内でミッションのパフォーマンス要件を満たすように順調に進んでいると判断します。^[13]

CDR の典型的な目的は次のとおりです: ^{[引用が必要]}

• 「構築」ベースラインに、機能要件とパフォーマンス要件を満たす詳細なハードウェアおよびソフトウェア仕様が含まれていることを確認します。
• 設計が製造、検証、運用、その他の専門エンジニアリング組織によって十分に監査されていることを確認する
• 製造段階に進むのに十分な生産プロセスと管理を確実に行う
• 計画された品質保証（QA）活動によって、品質の高い製品を生産するための知覚的な検証とスクリーニングのプロセスが確立されることを確立する
• 最終設計が PDR で確立された仕様を満たしていることを確認します。

PRR は、3 つ以上の、またはプロジェクトで決定された複数のシステムまたは類似のシステムを開発または取得するフライト システムおよび地上サポート プロジェクトに対して保持されます。PRR は、必要な数のシステムを効率的に生産するためのシステム開発者の準備状況を判定します。これにより、生産計画、製造、組み立て、統合を可能にする製品、および人員が配置され、生産を開始する準備ができていることが保証されます。

TRR は、テスト対象物 (ハードウェア/ソフトウェア)、テスト施設、サポート担当者、およびテスト手順がテストとデータの取得、削減、および制御の準備ができていることを保証します。これは、主要決定ポイントへのエントリの前提条件ではありません。

SAR は、特定の最終製品の完成度を、期待される成熟度レベルと比較して検証し、関係者の期待への準拠を評価します。SAR は、システム、その最終製品とドキュメント、および検証をサポートするテスト データと分析を検査します。また、指定された運用施設または発射場への出荷を承認するのに十分な技術的成熟度がシステムにあることも確認します。

ORR は、実際のシステム特性と、システムまたは最終製品の操作で使用される手順を検査し、すべてのシステムとサポート (飛行および地上) のハードウェア、ソフトウェア、人員、手順、およびユーザー ドキュメントがシステムの展開状態を正確に反映していることを確認します。

ORR の典型的な目的は次のとおりです。

• 利用可能な地上および飛行試験結果、分析、運用デモンストレーションの検査を通じて、システムが運用モードに移行する準備ができていることを確認します。
• すべての運用およびサポート モード (通常、緊急時、計画外) を考慮して、システムが運用上およびロジスティックス的に適切にサポートされていることを確認します。
• 運用文書が完全であり、システム構成と計画された運用モードを表していることを確認する
• トレーニング機能が整備されており、システムの保守、準備、運用、復旧のあらゆる側面をサポートする能力が実証されていることを確認します。

FRR は、安全で成功する飛行や打ち上げ、およびその後の飛行操作のためのシステムの準備状況を判断するテスト、デモンストレーション、分析、監査を検査します。また、飛行および地上のすべてのハードウェア、ソフトウェア、人員、手順が運用可能な状態であることを確認します。

FRR の 典型的な目的は次のとおりです^{[引用が必要] 。}

• 許容できるリスクで飛行操作を安全に続行できることの認定を受けます。
• システムとサポート要素が適切に構成され、起動の準備ができていることを確認します。
• すべてのインターフェースに互換性があり、期待どおりに機能することを確認します。
• システム状態が、go/no-go 基準に基づいて起動の「go」決定をサポートしていることを確認します。

• クリティカルパス法
• エンジニアリング設計プロセス
• システム開発ライフサイクル
• 技術ピアレビュー