アーキテクチャ上の概念の検証は、方向づけフェーズの初期に識別されるアーキテクチャ上の重要な要求に対するソリューションですが、これは概念的なものにすぎない場合もあります。 
役割:  ソフトウェア アーキテクト 
オプション度 / 使用時期:  問題領域が十分に理解されており、要求が十分に定義されており、システムの前例がいくつもあり、かつシステムの開発のリスクが低いと評価されている場合、アーキテクチャ上の概念の検証はオプションとしてもかまいません。 
テンプレートとレポート: 
 
例:   
UML の表現:  なし
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

アーキテクチャ上の概念の検証の目的は、アーキテクチャ上の重要な要求を満たすソリューションが存在する (または存在しそう) かどうかを判断することです。 

表現 ページの先頭へ

アーキテクチャ上の概念の検証には、以下の例のようにいくつもの形式があります。 

  • ソリューションに適していると思われる、既知の技術 (フレームワーク、パターン、実行可能なアーキテクチャ) のリスト
  • UML などの表記法を使用するソリューションの概念モデルのスケッチ
  • ソリューションのシミュレーション
  • 実行可能なプロトタイプ

タイミング ページの先頭へ

アーキテクチャ上の概念の検証は方向づけフェーズで作成し (オプション)、プロジェクトの実現可能性の判定、プロジェクトの開発に伴う技術的なリスクの評価、アーキテクチャ上重要な要求の定式化と改良などを補助することを目的とします。

責務 ページの先頭へ

ソフトウェア アーキテクトは、アーキテクチャ上の概念の検証に責任を持ちます。 

カスタマイズ ページの先頭へ

アーキテクチャ上の概念の証明が必要かどうか、またそれをどのような形式にするかについては、以下の要素を基に判断します。

  • 領域についての理解度 — 対象領域についての理解が不十分な場合、アーキテクチャ上の概念の検証を行うと、適用可能なソリューションが見つかるだけでなく、顧客と開発組織が要求を理解し、明確化するために効果的な場合があります。
  • システムの新規性 — 開発組織が既に同じようなシステムをいくつも構築している場合、概念の検証を行う必要はありません。実現可能性の判断は、既存の参照アーキテクチャと技術に基づいて行うことができます。
  • (対象領域の理解が十分でありシステムに先例がある場合でも) 要求のいずれかが特に困難であると判断されるかどうか。たとえば、非常に高いトランザクション率や絶対的な信頼性が要求される場合など。

リスクが高ければ高いほど、方向づけフェーズでのこのアーキテクチャ統合作業に (生成および評価したモデルからより現実的な結果が得られることを期待して) より多くの労力を費やす必要があります。そうすることで、資金を投入したり、推敲フェーズに移行したりするための根拠が信頼に足るものであることをすべての利害関係者が納得できるようになります。ただし、方向づけフェーズですべてのリスクを解消できるわけではないという点は認識しなければなりません。方向づけフェーズを事実上の推敲フェーズとしてしまうことは望ましくありません。



Rational Unified Process   2003.06.15