目的
  • アーキテクチャ上の重要な要求が実現可能であるか、また、この解決策またはそれ以外の解決策によってその要求に対処することができるかを判断するために、合成したアーキテクチャ上の概念の検証を評価する
手順
入力とする成果物: 結果となる成果物:
頻度: 方向づけの反復時に、おそらく 1 度のみ。
役割: ソフトウェア アーキテクト
ツール メンター:

ワークフローの詳細:

評価基準の決定 ページの先頭へ

アーキテクチャ上の概念の検証を評価する基準をアーキテクチャ上の重要な要求から導き出します。この重要な要求とは、概念の検証を作成する際の駆動力となったものです。

アーキテクチャ上の概念の検証に対する評価 ページの先頭へ

このステップでは、アーキテクチャ上の概念の検証を評価基準に照らしてテストします。テスト方法は概念の検証の形態によって異なります。たとえば、実行可能なプロトタイプの場合は、デモンストレーションによるテストを行います。概念モデルの場合は、検査と推論によるテストを行います。シミュレーションの場合は、評価基準から派生した入力データを使い、シミュレーション モデルをセットアップして実行し、モデルから出力データを収集して分析する必要があります。

結果の評価 ページの先頭へ

テスト結果を評価し、アーキテクチャ上の重要な要求を満たすことができるかを判断するだけでなく、そのような要求が妥当であるかもチェックします。開発のこの時点では、要求はまだ暫定的なので、利害関係者に十分理解してもらう必要はありません。たとえば、アーキテクチャ上の概念の証明のテストからリスクが高いことが明らかになった要求を緩和する機会があります。結果を評価する際は、これらのテスト方法すべてを完全に実行する必要があります。これは、後に行う推敲および作成のフェーズでの状況とは異なります。推敲および作成のフェーズでは、要求の変更や再解釈に対してはるかに大きな抵抗があるからです。評価後、概念の証明の範囲とその実現可能性について利害関係者全員の理解が深まったら、必要に応じて開発企画書、開発構想書、リスク リストに対する変更の提案を準備します。



Rational Unified Process   2003.06.15