作業:
|
目的
|
|
ステップ | |
入力とする成果物: | 結果となる成果物: |
役割: テクニカル レビュー担当者 | |
ツール メンター: | |
More Information: |
ワークフローの詳細: |
目的 | 各レビューの一般的な推奨事項を提供する。 |
2 万フィートの上空から見ると、ソフトウェア アーキテクチャ評価は、それ以外の評価やレビューとはほとんど区別が付きません。
ただし、ソフトウェア アーキテクチャで重要な特性の 1 つとして、多数あるアーキテクチャ品質属性の具体的な測定基準がないことが挙げられます。客観的に測定できるアーキテクチャ品質は、ほんの少ししかありません。性能は測定が可能な例の 1 つです。その他の品質は、さらに定性的または主観的です。たとえば、概念的な整合性です。さらに、比較対象のその他のデータや参照物がない場合に、測定基準が何を意味するかを決定するのが困難な場合がよくあります。参照システムが利用可能で、対象のレビュー担当者がそのシステムを理解している場合には、レビューの結果をこの参照システムと相対的に表すと便利な場合があります。設計中のシステムを以前の設計と比較できるようなコンテキストでは、このようなことが起こり得ます。
この評価がライフサイクル中のどの時点で起きるかということも、評価の目的や有効性に影響します。
「ピア」レビュー担当者の要員配置プロフィールは、ソフトウェア アーキテクトと同じものですが、ソフトウェア アーキテクトより技術的な問題に焦点を絞っています。リーダーシップ、成熟度、実用主義、結果主義などもある程度までは重要ですが、それより重要なことは、レビュー担当者が、プロジェクトの進行を妨げる可能性のあるアーキテクチャの障害を発見することです。また、スケジュールをむやみに進めてプロジェクト チームを誤った方向に向かわせるより、解決できるのであれば、重大な問題を早期に発見して処理することが大切です。アーキテクチャ レビュー担当者は、プロジェクトの成功に関わる幅広い問題に対して迅速に対応しながらも、コストに対するリスクのバランスを取る必要があります。また、アーキテクチャ レビュー担当者は、微妙な問題を指摘し、検討できる、説得力のある伝達者である必要があります。
目的 | レビューの範囲と目標を定義する。 範囲 / 目標の特定の組み合わせごとに使用するアプローチを定義する。 |
レビューには次のようなさまざまなアプローチを使用できます。
アーキテクチャの表現を入手 (またはビルド) し、この表現に基づいて質問および論証します。
ここでは幅広い状況が存在しています。アーキテクチャをよく理解していて、初めから分かりやすい説明ができる組織もあれば、まず誰がソフトウェア アーキテクトなのか (別の名前になっていて分からない場合もある) を明確にし、その人から取得した情報を、ソフトウェア アーキテクチャがまったく未知の概念である領域に配置する必要のある組織もあるからです。このプロセスは「アーキテクチャの発掘」と呼ばれ、文字通りの作業です。つまり、ソフトウェアまたはその文書を掘り出して、ソース コード、インターフェイス、構成データなどを検証します。
表現を整理する際は、ソフトウェア アーキテクチャ説明書に、アーキテクチャ ビュー形式で表示されているモデルを使用できます。論理ビューはメイン クラス (オブジェクト モデル) を構成し、プロセス ビューはメインの制御スレッドとその通信方法を記述します。開発ビューは各種のサブシステムとその依存関係を示し、物理ビューはほかのビュー要素の 1 つ以上の物理構成へのマッピングを記述します。各種のビューに沿って問題点を整理します。
論証に必要な情報のリスト (データ、測定値) を作成し、情報を取得し、この情報を要求または容認済みの参照標準と比較します。これは性能や堅牢さといった、特定の品質属性の調査に適しています。
これは、「もし~だったら」というアプローチをシステム的に適用するものです。一般的に尋ねられる質問を、システムで検証する一連のシナリオに変換し、そのシナリオに基づいて質問をします。このようなシナリオの例を次に示します。
このようなアプローチの利点は、誰でも理解できる非常に具体的な視点にタスクを持ち込めることです。このアプローチでは要求の抜けや不備を調査することもできます。特に、要求が非形式的であったり記述されていなかったりする場合や、非常に一般的で簡略すぎる場合にも使用できます。欠点としては、アーキテクチャ自体をレビュー対象のオブジェクトとして捉えないことであり、ブラック ボックスの中に調査機を送り込む程度にしかシステムを把握していないことです。
実際には、このように厳密に分離することはできないため、これらの 3 つのアプロ ーチを少しずつ使用することになります。
潜在的な問題の発見は、知識と経験に基づいて人間が判断を下すことです。特定の失敗パターンは、プロジェクトごと、組織ごとに繰り返されます。特定の発見的アプローチを使用して、問題の領域を明らかにできます。以前のレビュー結果や (もしあれば)、チェックリストも役に立ちます (非常に一般的なものを後で示します)。
潜在的な問題は、それらを検出した時点で把握し、個人を攻撃したり、大げさな説を持ち出したりすることなく、中立的な立場で説明します。優先順位を付けたり、整理したり、除外したりするのに、AT&T のレビュー担当者が使用するようなボール紙の小さなカードや CRC カード (ソフトウェアの設計段階でアイデアを抽出するのに使用する手法の 1 つ。オブジェクト指向に基くカード使用の問題解決法。CRC は、Class、Responsibility、Collaboration の頭文字) を使用することもできます。
後になってから、範囲や影響を減らして問題候補をソートします。多数の候補がある場合には、今抱えている問題に直接関係するものから処理します。「その他の提案」は、時間のあるときのために残しておきます。それから問題点の現実を主張します。問題を認知できる場合は非常に多いですが、そうでない場合もあります。話している相手が適切でない場合や、情報の間違った部分を指摘している場合があります。もう一度ソートします。複数のデータポイントにおいて、問題の現実を検証します (経験の浅い評価者は、1 つの視点からしか物を見ない傾向にあります)。
問題を確認したら、プロジェクト進行中にシステムの再設計をしなくても済むよう、どうすれば問題を除去できるか早急に調べます。潜在的な単純化、再利用、代替手段 (購入するか構築するか) を書き出します。
目的 | 識別された障害に対してアクションを実行する。 |
レビュー後に、識別した障害ごとに責務を割り当てます。この場合の「責務」は障害を修正することではなく、代替手段の追加調査を調整したり、障害の影響が大きく、範囲が広い場合に障害の解決を調整したりすることです。
Rational Unified Process
|