目的
  • スケジュールや予算に潜在する未知または認識済みのリスクを明るみにする。
  • アーキテクチャ設計の欠陥を検出する。アーキテクチャ上の欠陥は修正が最も難しく、長い目で見ると、最も損害が大きくなる。
  • 要求とアーキテクチャとの間の潜在的な不一致を検出する。過剰設計、非現実的要求、要求の欠如がこれにあたる。特に、評価では、運用、管理、保守の分野で軽視されることの多い部分を調査する場合がある。システムをどのようにインストールしたか、システムを更新したか、現在のデータベースをどのようにして移行するか、などを評価する。
  • 性能、信頼性、修正可能性、セキュリティ、安全性など、アーキテクチャ上の特定の品質を 1 つ以上評価する。
  • 再利用の機会を識別する。
ステップ
入力とする成果物:    結果となる成果物:   
役割:  テクニカル レビュー担当者 
ツール メンター:   
More Information: 

ワークフローの詳細:   

一般的な推奨事項 ページの先頭へ

目的 各レビューの一般的な推奨事項を提供する。

2 万フィートの上空から見ると、ソフトウェア アーキテクチャ評価は、それ以外の評価やレビューとはほとんど区別が付きません。

ただし、ソフトウェア アーキテクチャで重要な特性の 1 つとして、多数あるアーキテクチャ品質属性の具体的な測定基準がないことが挙げられます。客観的に測定できるアーキテクチャ品質は、ほんの少ししかありません。性能は測定が可能な例の 1 つです。その他の品質は、さらに定性的または主観的です。たとえば、概念的な整合性です。さらに、比較対象のその他のデータや参照物がない場合に、測定基準が何を意味するかを決定するのが困難な場合がよくあります。参照システムが利用可能で、対象のレビュー担当者がそのシステムを理解している場合には、レビューの結果をこの参照システムと相対的に表すと便利な場合があります。設計中のシステムを以前の設計と比較できるようなコンテキストでは、このようなことが起こり得ます。

この評価がライフサイクル中のどの時点で起きるかということも、評価の目的や有効性に影響します。

  1. 初期開発サイクルの方向づけフェーズの終わりでは、具体的なアーキテクチャはほとんど存在しないのが普通です。しかし、レビューを行うと、非現実的な目的、不足している項目、既存製品の再利用機会の見落としなどが発見されることがあります。
  2. ソフトウェア アーキテクチャの評価は、推敲フェーズの終わりに行うのが最も自然です。このフェーズでは、要求を詳細に探求したり、アーキテクチャをベースライン化したりすることに主に焦点を当てます。このマイルストーンでアーキテクチャのレビューを行うのが、プロセスの決まりごとになっています。ここでは、アーキテクチャの品質が広範囲に渡って調査します。
  3. 作成フェーズでは、さらに範囲を絞った評価を行い、性能や安全性などの特定の品質属性を調査します。また、作成フェーズの最後には、製品をエンドユーザーに提供するのが不適切となりかねない問題がある場合は、それらを調査します。
  4. 作成フェーズの後半や移行フェーズで、作成が完了しない、移行時にインストール ベースで容認できないレベルの問題が発生した、などの深刻な事態になった場合は、被害対策評価を行う場合があります。
  5. 最後に、最終的な新製品や発展サイクルについて、特に再利用可能な資産の目録を作成するための評価が移行フェーズの終了時に行われる場合があります。

「ピア」レビュー担当者の要員配置プロフィールは、ソフトウェア アーキテクトと同じものですが、ソフトウェア アーキテクトより技術的な問題に焦点を絞っています。リーダーシップ、成熟度、実用主義、結果主義などもある程度までは重要ですが、それより重要なことは、レビュー担当者が、プロジェクトの進行を妨げる可能性のあるアーキテクチャの障害を発見することです。また、スケジュールをむやみに進めてプロジェクト チームを誤った方向に向かわせるより、解決できるのであれば、重大な問題を早期に発見して処理することが大切です。アーキテクチャ レビュー担当者は、プロジェクトの成功に関わる幅広い問題に対して迅速に対応しながらも、コストに対するリスクのバランスを取る必要があります。また、アーキテクチャ レビュー担当者は、微妙な問題を指摘し、検討できる、説得力のある伝達者である必要があります。

推奨されるレビュー会合 ページの先頭へ

目的 レビューの範囲と目標を定義する。
範囲 / 目標の特定の組み合わせごとに使用するアプローチを定義する。 

レビューには次のようなさまざまなアプローチを使用できます。

  • 表現主体
  • 情報主体
  • シナリオ主体
表現主体のレビュー

アーキテクチャの表現を入手 (またはビルド) し、この表現に基づいて質問および論証します。

ここでは幅広い状況が存在しています。アーキテクチャをよく理解していて、初めから分かりやすい説明ができる組織もあれば、まず誰がソフトウェア アーキテクトなのか (別の名前になっていて分からない場合もある) を明確にし、その人から取得した情報を、ソフトウェア アーキテクチャがまったく未知の概念である領域に配置する必要のある組織もあるからです。このプロセスは「アーキテクチャの発掘」と呼ばれ、文字通りの作業です。つまり、ソフトウェアまたはその文書を掘り出して、ソース コード、インターフェイス、構成データなどを検証します。

表現を整理する際は、ソフトウェア アーキテクチャ説明書に、アーキテクチャ ビュー形式で表示されているモデルを使用できます。論理ビューはメイン クラス (オブジェクト モデル) を構成し、プロセス ビューはメインの制御スレッドとその通信方法を記述します。開発ビューは各種のサブシステムとその依存関係を示し、物理ビューはほかのビュー要素の 1 つ以上の物理構成へのマッピングを記述します。各種のビューに沿って問題点を整理します。

情報主体のレビュー

論証に必要な情報のリスト (データ、測定値) を作成し、情報を取得し、この情報を要求または容認済みの参照標準と比較します。これは性能や堅牢さといった、特定の品質属性の調査に適しています。

シナリオ主体のレビュー

これは、「もし~だったら」というアプローチをシステム的に適用するものです。一般的に尋ねられる質問を、システムで検証する一連のシナリオに変換し、そのシナリオに基づいて質問をします。このようなシナリオの例を次に示します。

  • システムはプラットホーム X と Y で動作します (ここで調査される品質属性は移植性)。
  • システムはこの (追加) 機能 F を実行します (真の品質属性は拡張可能性)。
  • システムは 1 時間あたり 200 個の要求を処理します (真の品質属性はスケーラビリティ)。
  • この種のサイトへのシステムのインストールは、エンドユーザーが行います (真の品質属性は完全性または使いやすさ)。

このようなアプローチの利点は、誰でも理解できる非常に具体的な視点にタスクを持ち込めることです。このアプローチでは要求の抜けや不備を調査することもできます。特に、要求が非形式的であったり記述されていなかったりする場合や、非常に一般的で簡略すぎる場合にも使用できます。欠点としては、アーキテクチャ自体をレビュー対象のオブジェクトとして捉えないことであり、ブラック ボックスの中に調査機を送り込む程度にしかシステムを把握していないことです。

実際には、このように厳密に分離することはできないため、これらの 3 つのアプロ ーチを少しずつ使用することになります。

問題の特定

潜在的な問題の発見は、知識と経験に基づいて人間が判断を下すことです。特定の失敗パターンは、プロジェクトごと、組織ごとに繰り返されます。特定の発見的アプローチを使用して、問題の領域を明らかにできます。以前のレビュー結果や (もしあれば)、チェックリストも役に立ちます (非常に一般的なものを後で示します)。

潜在的な問題は、それらを検出した時点で把握し、個人を攻撃したり、大げさな説を持ち出したりすることなく、中立的な立場で説明します。優先順位を付けたり、整理したり、除外したりするのに、AT&T のレビュー担当者が使用するようなボール紙の小さなカードや CRC カード (ソフトウェアの設計段階でアイデアを抽出するのに使用する手法の 1 つ。オブジェクト指向に基くカード使用の問題解決法。CRC は、Class、Responsibility、Collaboration の頭文字) を使用することもできます。

後になってから、範囲や影響を減らして問題候補をソートします。多数の候補がある場合には、今抱えている問題に直接関係するものから処理します。「その他の提案」は、時間のあるときのために残しておきます。それから問題点の現実を主張します。問題を認知できる場合は非常に多いですが、そうでない場合もあります。話している相手が適切でない場合や、情報の間違った部分を指摘している場合があります。もう一度ソートします。複数のデータポイントにおいて、問題の現実を検証します (経験の浅い評価者は、1 つの視点からしか物を見ない傾向にあります)。

問題を確認したら、プロジェクト進行中にシステムの再設計をしなくても済むよう、どうすれば問題を除去できるか早急に調べます。潜在的な単純化、再利用、代替手段 (購入するか構築するか) を書き出します。

障害解決責務の割り当て ページの先頭へ

目的 識別された障害に対してアクションを実行する。 

レビュー後に、識別した障害ごとに責務を割り当てます。この場合の「責務」は障害を修正することではなく、代替手段の追加調査を調整したり、障害の影響が大きく、範囲が広い場合に障害の解決を調整したりすることです。



Rational Unified Process   2003.06.15