成果物:
|
![]() |
アーキテクチャ上の概念の検証は、方向づけフェーズの初期に識別されるアーキテクチャ上の重要な要求に対するソリューションですが、これは概念的なものにすぎない場合もあります。 |
役割: | ソフトウェア アーキテクト |
---|---|
オプション度 / 使用時期: | 問題領域が十分に理解されており、要求が十分に定義されており、システムの前例がいくつもあり、かつシステムの開発のリスクが低いと評価されている場合、アーキテクチャ上の概念の検証はオプションとしてもかまいません。 |
テンプレートとレポート: |
|
例: | |
UML の表現: | なし |
詳細情報: | |
成果物を入力とする作業: | 成果物を出力とする作業: |
アーキテクチャ上の概念の検証の目的は、アーキテクチャ上の重要な要求を満たすソリューションが存在する (または存在しそう) かどうかを判断することです。
アーキテクチャ上の概念の検証には、以下の例のようにいくつもの形式があります。
アーキテクチャ上の概念の検証は方向づけフェーズで作成し (オプション)、プロジェクトの実現可能性の判定、プロジェクトの開発に伴う技術的なリスクの評価、アーキテクチャ上重要な要求の定式化と改良などを補助することを目的とします。
ソフトウェア アーキテクトは、アーキテクチャ上の概念の検証に責任を持ちます。
アーキテクチャ上の概念の証明が必要かどうか、またそれをどのような形式にするかについては、以下の要素を基に判断します。
リスクが高ければ高いほど、方向づけフェーズでのこのアーキテクチャ統合作業に (生成および評価したモデルからより現実的な結果が得られることを期待して) より多くの労力を費やす必要があります。そうすることで、資金を投入したり、推敲フェーズに移行したりするための根拠が信頼に足るものであることをすべての利害関係者が納得できるようになります。ただし、方向づけフェーズですべてのリスクを解消できるわけではないという点は認識しなければなりません。方向づけフェーズを事実上の推敲フェーズとしてしまうことは望ましくありません。
Rational Unified Process
|