軽量評価の鍵は、適切なものを適切なタイミングで評価することです。これを効果的に行う方法は2つあります。では、シナリオベースの評価あなたは、優先度の高い品質属性にのみ焦点を当てた評価を駆動するための品質属性のシナリオやユースケースを使用します。では、リスクベースの評価あなたはリスクを特定し、特定されたリスクは、お使いのアーキテクチャの設計活動を推進しましょう。
これらの2つの（やや関連する）アプローチを検討するために推奨できる2冊の本があります。
Anthony LattanzeによるArchitecting Software Intensive Systemsは、Architecture Centric Design Methodologyを紹介し、軽量のシナリオベースの評価をカバーしています。SEIの品質属性ワークショップでLattanzeを認識できますが、同様のアイデアが関係しています。
Just Enough Software Architecture：a Risk-Driven Approach by George Fairbanksは、ソフトウェアシステムのアーキテクチャを設計および評価するためのリスク主導型のアプローチを紹介しています。また、プレビューが必要な場合は、彼のWebサイトで利用できる無料の章もいくつかあります。この本の原則はすぐに適用されますが、このアプローチには特定の方法が付属していないため、他の分野のアイデアを組み合わせる必要があります。リスクの特定/優先順位付けのためのSEIの継続的なリスク管理アプローチを強くお勧めします。
これらのアプローチの背後にある基本的な考え方は、最後まで待つのではなく、進行中に評価することにより、評価（および設計）のコストを削減することです。これは確かにホワイトボードの周りで話すよりも少し重いですが、完全に吹き飛ばされたATAMほどコストがかかる場所ではありません。また、問題がなければ、特定のニーズを満たすための方法を選ぶことができます。
評価を推進するためにどのアプローチを使用しても、一般的な考え方は同じです...
始める前に：
- 優先順位付けされた品質属性のシナリオまたはリスク（それがすべての場合は非公式にすることができます）
- 続行/中止の決定の明確な定義（アーキテクチャが「十分」であるとどうしてわかるか）
- アーキテクチャ記述の最新のカット（評価しているアーティファクト）
評価セッションにご参加ください：
- 建築家は建築の概要を提示します
- ビューをウォークスルーし、シナリオまたはリスクがどのように満たされているかを示します
- 問題は後で修正するために記録されます
- 役割と一般的な手順は、Faganの検査（建築家または著者、モデレーター、レコーダー）に使用されるものと同様です。
- システムのサイズによっては、セッションに1〜2時間かかる場合があります。
セッションが終了したら：
- 識別された問題を確認し、合格/不合格の基準が満たされているかどうかを判断します。一般に、すべてがうまくいくには約3件のレビューが必要です。満たされていない場合は、改良と実験を繰り返します（またはアーキテクチャのリスクを軽減します）。
- これは「オールオアナッシング」の評価ではありません。アーキテクチャのさまざまな部分が「合格」する一方で、他の部分にはまだ改良が必要です。
シナリオベースのアプローチがどのように見えるかを理解してもらうために、私が大学院で取り組んだキャップストーンプロジェクトの公開ドキュメントがあります。ドキュメントは少し大まかなものですが、ACDMのコンテキスト内でのシナリオベースのアプローチの例をいくつか示すのに役立ちます。私たちは5人のチームで、約35 KLOC Java / GWTの典型的なWebベースのアプリケーションを構築しました。