從20世紀90年代開始，因爲系統架構的全方位興起（例如面向對象的架構技術、構 件技術、架構與設計模式等），愈來愈多的從業人員認識到提升架構和設計質量的重要性。 這使得架構評審獲得了飛躍式的演化。經過近十幾年的發展，架構評審己經有了長足的進 步。咱們如今能夠看到業界許多體系化的架構評審方法和評審技術，例如：SAAM、ATAM、 SAAMCS、CBAM、ARID、SPE、SAAMER、SAEM、SBAR、EASSMK ALPSft/^。
如此之多的評審方法和技術，有其各自的應用場合和質量關注點。那麼在現實中，如 果面對一個系統或者一個子系統要求咱們對其進行一次架構評審，到底應該選擇怎樣的評 審方法或評審技術來進行操做呢？這個問題會引起以下一連串的問題。
•架構評審的總目標應該是什麼？
•架構評審應該邀請哪些人蔘加？
•爲了進行架構評審，咱們須要蒐集和分析哪些系統架構相關的信息或文檔？
•架構評審應該遵循怎樣的流程或步驟？
•進行架構評審時，應該問一些怎樣的問題？應該驗證哪些方面？
•評審中須要使用怎樣的模板進行工做？
•評審結束時應該有哪些必要的總結信息？
在詳細探討上述問題前，咱們能夠先來看看如圖6-1所示的這個系統架構評審概念模型。
從該系統架構評審概念模型中，咱們能夠看到一個體系化的系統架構評審，有以下幾 個主要的方面和階段：
須要肯定架構評審的約束條件，這其實就是架構評審工做的主要目標要求；並與 Stakeholders 一塊兒最終肯定評審的範圍和重點。
根據評審的目標要求和評審重點，肯定架構評審主要參與者與時間安排；同時肯定 進行評審的主要評審方法或評審技術，最終造成評審計劃。
根據肯定的評審目標及評審方法和技術，與評審主要參與者一塊兒肯定評審須要的輸 入信息和輸入文檔。
根據肯定的評審方法或評審技術的流程要求進行評審工做。
在實現評審目標的前提下，產生相應的最終評審輸出。
將該評審概念模型進一步分解，就能夠看到如圖6-2所示的更加詳細的評審過程流程, 咱們稱之爲ARP架構評審流程（Architecture Review Process)D
6.1架構評審目標肯定
咱們首先來看看哪些人會關注系統的質童，這些人也是咱們常說的所謂Stakeholders: 系統開發的出資方、最終用戶、產品線/產品管理人員、公司技術管理人員、系統架構和設 計人員、系統開發人員、系統維護人員、子系統或構件的提供商、產品銷售人員、產品支 持人員、流程管理人員等。這麼多不一樣的Stakeholders所關注的問題也大爲不一樣。例若有 些Stakeholders關注系統功能性質童；有些Stakeholders關注非功能性質量；有些對產品 的發展前景（對系統架構來說，多是可修改、可替換、可擴展能力等）很是關注。
一般促使對一個系統架構進行評審，主要是因爲這些Stakeholders對正在構建中的系 統內心沒有足夠的信心。尤爲是在技術或架構方面，他們並不知道本身所關心的問題是否被架構很好地解決；系統架構人員面臨管理層的壓力，他們也但願可以利用評審來確保自 己構建的架構質量，同時爲本身說服管理層作出某些讓步創造一次溝通機會；除此以外， 因爲公司內部的系統開發流程或規章制度的要求，也會造就了項目或產品開發必須在其特 定階段進行架構和設計評審。
能夠看出各個Stakeholders對系統架構的側重點截然不同。這樣的狀況也就天然而然 形成咱們在接收架構評審請求時，肯定的評審目標也會大不同。通常來講，咱們能夠這些目標分爲下面幾種類型：
•驗證架構和設計的和規性。其主要目的就是檢驗系統架構是否知足了國際、國家、 行業的標準、法規和流程。
•增進架構和設計的溝通交流。這能夠包括非技術背景的stakeholders (例如：管理 層、銷售人員)和系統架構人員深刻交流系統架構的詳細細節，從而避免由於溝通 不順暢所致使的擔心；便於利用評審的機會讓Stakeholders和架構設計人員進行有關 架構及設計抉擇的溝通’從而在理解的基礎上達成一致或妥協。
♦評估架構和設計的質量。這包括：架構是否圓滿地完成了功能的須要；架構是否爲 將來增補的需求提供了可擴展空間；需求中明確要求的那些特定的非功能性（例如： safety、performance)的要求是否在架構中獲得合理的考慮和解決；是否有什麼懸 而未決的架構及設計抉擇；架構和設計在實現中是否可行；爲了實現架構和設計而 選擇的技術實現手段是否可行或有效等。
•發現架構和設計的改進點。例如：哪些架構和設計方面能夠進行進一步的優化以及 這種優化的成本和代價；以怎樣的原則或度量方式來衡量改進的程度；識別系統架 構和設計中的錯誤所帶來的危險等。
因爲評審目標來自不一樣的Stakeholders,他們各自的側重點又屬於上述不一樣類型。這 就要求評審人員必須在評審工做開始前，根據評審整體目標與相應的stakeholders —起精 肯定義這次評審的重點。注意：肯定清晰的評審重點是評審成功的一個重要約束條件。例 如咱們一般可讓Stakeholders回答相似下面的問題來進行提示和澄淸：
•這次架構和設計評審包括系統的哪些部分？是整個系統，仍是某些子系統？是否包 括硬件系統、通訊網絡等？
•評審中要覆蓋系統整個的需求，仍是選定那些特定的關鍵需求？
•評審中爲了評估各類架構及設計抉擇是否知足需求，須要評審全部的架構及設計抉 擇，仍是選擇那些關鍵的架構抉擇？
•是否要將全部的架構和設計結果進行深刻的評估？架構評審要達到怎樣的縱向深度？
通過這樣一系列的工做後，咱們已經徹底澄清了這次評審的目標，而且清晰而一致地 勾畫出評審的重點或範圍。例如一個關於評審目標簡單的例子能夠這樣來表述：咱們已經 知道這次評審是爲了解決最終用戶（評審發起人）對系統性能的擔心（評審目標）而進行 的一次有關整個系統架構中與性能相關（評審重點）的那些架構及設計抉擇的考童評審。
6.2架構評審計劃制定
架構評審目標和評審重點肯定後，就能夠開始進行評審的準備工做了。首先，須要在 人員上進行準備。一般，參與評審的人有這樣的三種類型：
•評審組成員：這能夠包括主評審員（Lead Reviewer)、輔助評審員（Reviewer)和 觀察員（Observer)。通常系統架構評審，須要雙數配對進行工做，一個主評審員 結合一個普通評審員。這樣作的主要目的是方便進行對比交叉驗證。若是是針對系 統內各個子系統進行評審’對每一個子系統的評審須要一主一輔搭配進行。另外，任 何重點問題的評判或裁決只容許由主評審員與Stakeholders進行交流。常常咱們也 會遇到有觀察員參加的評審，這些觀察員能夠來自評審方，也能夠來自被評審方的 學習人員.
• Stakeholders或其表明：這些評審參與者主要是那些關注系統各方面質量的人員。
例如：最終用戶可能對產品是否知足功能的要求及系統性能這兩個方面很是關注。
•參加面談和校驗的人員：這些人員一般參與了由評審小組組織的各類面談或驗證活 動的人員。經過面談或驗證活動，他們能夠向評審組提供最爲真實可信的系統開發信 息。例如：系統測試人員能夠幫助驗證系統的性能是否知足特定的要求；系統架構組 成員能夠向評審組解釋爲了某個特定質量要求，系統架構所進行的架構手段抉擇。
評審方法或評審技術的選擇，是制定評審計劃的第二個重要步驟。因爲Stakeholders 側重點不一樣，要進行的架構評審也有着明顯的側重，可選用的評審方法或評審技術也就各 不相同（咱們會在第6.4節中，談到那些可選用的評審方法或評審技術）。基於評審所選定 的方法或技術，評審時間和進度安排也不盡相同。例如一個針對系統性能的評審，咱們可 選用「SPE (Software Performance Engineering)」軟件績效工程評審方法，而「SPE方 法在評審時間和進度安排方面與「SBAR (Scenario-Based Architecture Reengineering)’， 基於場景的評審方法大不相同。
評審人員與評審方法的肯定，已經爲咱們制定評審計劃作好了鋪墊。根據選定的評審 方法，評審進行中的重要活動（不一樣的評審方法和技術有其不一樣的評審活動）也就能夠完 全，定下來。最後，咱們要安排一個評審時間進度表。根據現實中發生的架構評審的統計 顯示，通常會有以下幾種評審類型（根據系統複雜度、技術成熟度等的不一樣，評審工做量 會進行相應的上下調整）。
•全面評審：一個完整系統的架構評審，須要6~8人，約3〜4周的時間。
•快速評審：子系統級的架構評審，一般須要2~4人，約2周的時間。
重點評審：系統範圍內，選擇重點問題（例如系統可靠性）進行評審，一般須要2〜4 人，約1-2周的時間。
•決策評審：一個系統全局範圍內重大決策（項目繼續進行或者中止），須要6~8人， 約3~4周的評審時間。
■ 6.3架構評審輸入收集
在架構評審中，咱們不僅僅要和各方進行口頭的交流。更爲重要的是，咱們須要看到 落實在文檔中的那些證據。識別這些重要的架構評審輸入信息，對架構評審的成敗有着重 要的影響。
在系統架構評審開始前，咱們一般會從如圖6-3所示的幾個方面蒐集相應的文檔*做 爲咱們進行評審的依據。
輸入1:系統描述
爲了使系統架構評審人員可以淸晰地看到該系統開發的背景，系統描述須要淸晰記錄 「爲何要開發該系統」或「但願系統完成怎樣的使命」等。一個典型的系統描述通常會包
含下述信息。
商業功能：該系統的開發對一個商業公司或組織有着怎樣的功能方面的便捷；該系 統的開發是否隸屬於商業產品戰略的一部分等。
•最終用戶：該系統的最終用戶有哪些；這些用戶的要求是怎樣的。
系統功能概述：該系統應該提供哪些主要的功能；是否須要和其餘應用協做；系統 應該提供怎樣的外部接口；用戶和系統有哪些主要的交互動做等。
輸入2:產品戰略及產品計劃描述
一個產品戰略每每是依賴於市場調研和分析後的結果來制定的。這樣的產品戰略才能 真正表明市場中最終用戶的須要。根據競爭對手的狀況（例如產品分佈、產品優點/劣勢等） 及當前自身所處的市場競爭位置，參照市場競爭環境和競爭對手的產品，產品戰略一般會 規劃一個產品或產品家族在市場上的定位。
競爭定位：該系統是爲了佔領市場的哪個位置或哪一部分市場份額。
競爭原則：該系統取得市場競爭力的原則，例如：依賴價格優點、依賴質量優點
制定產品戰略的下一個步驟，就是要製做詳細的產品計劃，這包括：
•產品/產品線路線圖：規劃將來產品的演化路徑、產品家族成員的生命週期、產品的 發佈時間及發佈版本等。
技術及經濟因素：進行投入及產出分析、訂價分析、技術演化路線圖、技術能力培 養計劃等。
架構評審之因此須要考慮產品戰略及產品計劃的要求，就是由於這些戰略層面的指導 原則會嚴重影響產品對架構的要求，這也是一個系統架構存在的特定背景之一。系統架構 是否知足產品戰略及產品計劃的要求，也是咱們評審的一個衡量標準。
輸入3:需求描述
做爲架構評審的一個最基本的輸入，「需求描述」是咱們進行架構質量評判的一個重要準 繩。咱們都知道，一個系統架構其實就是以技術的表達方式，來說述那些需求是如何被實現的。
IEEE STD 610.12.1990曾經定義過下述需求，這也就是咱們但願看到的評審輸入。
* 功能需求：「It specifies a function that a system or system component must be able to perform, without taking physical constraints into consideration」。簡而言之， 就是系統必需提供的服務或功能，及其相應必須的榆入和輸出。
•設計需求：「It specifies or constrains the design of a system or system component」。架構期間或系統設計階段必須遵循的規約。
* 接 口需求：「It specifies an external item with which a system or system component must interact, or that sets forth constrains on formats, timing, or other factors caused by such an interaction"0系統接口必需遵循的要求。
* 實現需求：「It specifies or constrains the coding or construction of a system or system component"0編碼實現階段的要求。
* 非功能性需求：「It imposes conditions on a functional requirement; for example, a requirement that specifies the speed, accuracy, or memory usage with which a given function must be performed^在功能需求之上所加的一些條件，例如速度、 精確性、內存容量等。
一物理需求：「it specifies a physical characteristic that a system or system component must possess; for example, material, shape, weight」。物理特性方面 的需求，例如材料、形狀、重量等。
在實踐中，咱們每每拿不到這麼完整清晰系統化的需求描述文檔。可是，需求的分類 能夠在很大程度上幫助咱們在後續的評審中有意識地從各個Stakeholders那裏澄淸上述需求。
輸入4:重點需求描述
「需求描述」只是表明了各個Stakeholders的關注點，這些關注點是組成咱們評審準 尺的基礎。可是，這些關注點中，有些是與系統架構層面緊密相關，有些則不是架構所應 考慮的問題。有時候，一些須要重點關注的問題，卻沒有在「需求描述」中描述出來或者 在行文中只是輕描淡寫地進行了表述。因此咱們應該將這些需求進行提煉並造成系統化、 有重點的描述，即所謂的「重點需求描述」《必須清晰而有重點地細化Stakeholders的需 求，這將會是後續進行重點評審的工做。若是隻是泛泛地走一遍架構評審過程，將無益於 解決Stakeholders的問題和疑慮。
輸入5:架構描述
做爲架構評審最重要的輸入信息之一，系統架構描述將幫助評審人員識別 Stakeholders所提出需求的技術實現手段。架構描述須要全面回答解決問題的各類方法和 步驟，尤爲重要的是，它須要記錄爲實現需求所作出的技術方面的架構及設計抉擇。
可是，在現實中進行架構評審時，咱們常常看到的架構描述文檔，要麼太過空泛或抽 象，要麼太過細節層面的設計文檔。這樣的文檔並無提供足夠的信息供咱們理解系統架 構構建是怎樣知足Stakeholders的需求。這就要求咱們在架構評審過程當中不斷地收集和匯 總相關的架構信息。一般咱們會以不一樣的視角來收集和整理架構信息。例如：咱們能夠以 「系統性能」爲一個架構視角，在評審過程當中，從系統硬件分佈和配置信息、線程及優先級 設計規約、系統接受事件的排序或調度等方面來收集證據，幫助咱們理解系統架構是如何 保障系統性能的要求以及作出了哪些架構抉擇。
輸入6:架構抉擇描述
架構描述幫助咱們理解了架構人員在進行系統架構構建時最終採用了怎樣的方式來解
決問題，從而來知足業務需求。可是•除了架構描述外，若是咱們在進行評審前就能夠
拿到一份全系統範圍內全部架構及設計抉擇的彙總表，即所謂的「架構抉擇描述」，將很是有 利於後續驗證這些抉擇是否真正符合要求。由於「架構描述」並無告訴咱們架構人員爲 了構建系統架構所經歷的痛苦抉擇過程，評審人員也並不知道系統架構中哪些是這些痛苦選擇的位置。例如：爲了解決整個系統的性能問題，通過仔細考慮，架構人員計劃在子系 統A和D中’都增長一個構件’該構件準備「使用中央資源Scheduling方法，而不採用 資源Queuing的方式來進行資源管理」，這就是一個架構及設計抉擇。
輸入7:經驗使用點
隨着系統架構方面的發展’大量的最佳經驗和實踐已經總結出來並被不少系統架構人 員所普遍複用（例如：架構原則、架構風格、設計模式、參考架構模型等）。若是在進行架 構評審前，咱們可以獲取一份有關該系統所使用的經驗彙總，將很是有利於評審人員理解 和衡量該系統的架構質量。由於複用這些最佳實踐的目的，每每是爲了經典而有效地解決 問題。這也天然而然地成爲評審人員能夠重點評審和驗證的一些架構關鍵點。
輸入8:架構/設計指南和規範
在有關係統架構的描述性文檔中，除了架構描述、架構抉擇描述以外，爲了對架構構 建和後續設計工做進行強制約束，還會有一份「架構/設計指南和規範」文檔。通常來說，「架構/設計指南和規範」是公司範圍內的一份規範性文檔，並非爲每一個項目或產品定製 製做的。可是它的約束性也是評審人員須要參考的重要輸入信息之一。
架構、設計及編碼規則。例如：構件、對象、接口的命名規則接口調用規則、message 或數據格式規範、異常處理規則、存取控制規則等。
公共機制或服務規範。例如：郵件服務、共享內存管理等。
數據庫及存儲設計規範。
測試規範。例如：測試環境、測試手段、測試工具等。
文檔及格式規範。
架構控制流程。
輸入9:系統相關證據
評審方法和評審技術有時會須要一些相關的證據，從而幫助驗證那些關鍵但沒法切實 驗證的方面。這些證據包括：
•可行性研究：該技術報告有力地證實了架構抉擇的動態選擇和驗證過程。可行性報 告每每告訴評審人員，架構組爲了驗證某些特定的需求是否能夠實現而記錄的探索 性驗證文檔。
•系統原型：評審人員能夠在系統原型的幫助下，驗證那些難以從紙面或推理得出的 驗證性評審結果。例如：系統性能的評審每每只能從推理中獲得部分的驗證，通常 能夠結合使用原型進行進一步的試驗。
•會議記錄、交流筆記：這些證據充分記錄了當初架構人員在進行架構和設計過程當中 的一些重要架構抉擇和討論過程，代表最終造成當前架構和設計的過程、曾經發生 過的問題和相應的解決方案。
•度量標準：反映了架構和設計過程當中遵循的衡童體系。這也是評審人員以怎樣的硬 性度量尺度分析架構和設計的依據。
輸入10:系統標準及約束描述
「系統標準及約束描述」每每是伴隨着用戶需求而必須強制執行的一些硬性標準和約 束，這也是評審人員須要着重評審和規性（compliance)的一個重要標尺。這些標準和約 束能夠包括：
•國際標準。例如：國際電報電話通行標準、國際財務準則。
•國家標準。例如：中國食品藥品標準、美國財務準則。
•國家法律法規。例如：道路交通法。
•行業標準。例如：IEEE80二、IS027001標準。
•公司標準。例如：架構和設計標準文檔。
除了上述的標準以外，還有一些約束規則須要評審人員進行和規性（compliance)驗 證。例如：
•系統架構與老系統的兼容或集成能力。
•系統架構應該儘可能使用公司現有資產。
•社會政治方面的和規性。例如：系統架構應該避免使用「中華民國」這樣的政治敏 感字眼；考慮到中國民族習慣，頁面顏色不該該是紅色配綠色；阿拉伯的文字閱讀 習慣是自右向左閱讀文字等^
•分佈開發的因素。系統架構應該儘可能保證分佈式的開發。
在實踐中，Stakeholders每每可能忽略了要求評審人員審覈系統架構和設計的和規性。 可是，爲了保證架構和設計的質量’評審人員應該衡量系統和規性的方方面面。
輸入11:商業信息描述
一個大規模複雜系統的建立和維護，須要後期大量經濟方面的支撐。例如：航空母艦 的建造費用並非很是高’可是其每一年的維護費用卻高得驚人。這也就意味着，一個系統 架構和設計的過程，每每嚴重地受制於商業因素的影響。做爲架構評審人員，咱們應該考 慮到商業因素對咱們的系統架構有着哪些重要的影響。這須要在架構評審初期明確獲得商 業方面的信息輸入，包括項目或產品用於設計和生產的投資、維護成本的預算、產品演化 所計劃的費用、投資所帶來的短、中長期R0丨計算等。
這些重要的商業輸入信息能夠幫助評審人員明確地驗證一個系統架構及設計抉擇的商 業成本和受益。每種架構抉擇都有其短、中、長期的投入產出比。沒有商業信息進行約束 的架構天然違反了商業的投資策略。業界已經有了專門針對商業問題進行架構評審的標準 技術’例如 SE丨的 CBAM (Cost Benefit Analysis Method)評審技術。
輸入12:其餘相關文檔
爲了儘量多地理解一個系統架構的構建過程，其餘輔助文檔和信息對評審人員也會 有幫助，例如：
•項目/產品組織結構文檔：能夠表述架構、設計、測試等人員的職位、職責、關係分 布的信息。
•員工我的信息：做爲溝通的基礎，員工我的信息可以有效提高針對我的特色的溝通
效率。
•過程性文檔：例如，項目過程當中的風險管理文檔能夠有效地幫助評審人員回顧項目 進行中發生過的風險及其識別和應對方法。
6.4架構評審方法和技術選擇
系統架構評審在目標明確後，會制定一份評審計劃。評審計劃中的一個重要的動做就 是根據評審目標和評審重點，肯定將要使用的架構評審方法或評審技術。一個評審方法或 技術基本上會包括：評審人員的角色劃分、評審時的步驟或動做、所使用的分析技術、所 使用的模板和標註方式等。只有在確立評審方法和技術後，後續的評審輸入信息的蒐集、 評審的進行以及評審的輸出都是徹底圍繞着將要使用的評審方法和技術而展開的。
談到評審方法和評審技術，業界雖然早在20世紀80年代後期就開始嘗試使用各類不 同的方法和技術進行系統架構評審。可是，直到20世紀90年代初期，在美國國防部專項 基礎研究資金的大力推進下，卡內基梅隆大學軟件工程研究所（SEI)在Len Bass、Paul Clements 和 RickKazman 的研究基礎上，正式對外發布了 SAAM (Software Architecture Analysis Method)軟件架構分析評審方法。這是業界第一個有着完總體系的實用架構分析評審技術（業界有不少重要的實踐和標準都來自美國國防部和美國國家航天局，主要緣由 是它們每每前瞻性地進行了大量大規模複雜系統的實踐，這些實踐後來成爲了事實上的業 界標準)。隨着SAAM奠基了架構分析評審基礎，美國國家航天局等大量的機構也開始使用或研究系統架構分析評審技術，這標誌着該領域開始走向繁榮。
經歷近十幾年的演化，雖然系統架構分析評審方法和技術己經有了長足的發展，但總 體來說，仍是基本上遵循了 Paul Clements、Rick Kazman和Mark Clein在1998年所指出的方向。系統架構分析評審方法和技術基本有三種類型：「提問技術」、「度量技術」和「混 合技術」。
提問技術（Questioning Technique)：這是一種定性方式的架構分析和評審方法。 主要經過問卷（questionnaire)、檢查表（checklist)、場景（scenario)等方式來 分析和評價一個系統架構是否知足了各類質量方面的要求。提問技術主要是經過架 構體系各個視角的審視，經過經驗或最佳實踐來推測將來系統的行爲。通常進行提 問評審時，系統尚未編碼實現成爲實際運行的系統。
度量技術（Measuring Technique):這是一種定量方式的架構分析和評審方法。通 常，使用這種技術每每是在一個系統已經基本編碼完成或部分完成的狀況下，應用 相應的度量手段或工具，對系統進行量化的分析和評價。度f技術能夠包括運用原 型的方式來評測系統的性能在最大峯值輸入時的表現；使用指標（Metrics)來定量 地衡f系統架構如何應對併發事件的處理能力；應用一些自動化工具來模擬和評測 系統內構件間的耦合程度和是否存在潛在的調用死鎖等。
混合技術（Hybrid Technique):結合定量分析和定性分析的優勢和長處，在架構評 審時混合使用多項提問技術和度量技術。在實踐中，若是有些定性分析不能深刻洞 悉，或者不能徹底肯定問題的癥結，這時就能夠結合使用定量分析的結果做爲定性 的依據。而定量分析的前提其實就是帶着須要定性的問趙進行的。這二者不能徹底 剝離開，例如：咱們能夠定量分析系統範圍內資源的調度和使用狀況，這其實也部 分回答了 「系統的性能如何」這樣一個定性的問題。
基於上述類型，比較有表明性的架構評審方法和評審技術包括：
• SAAM (Software Architecture Analysis Method)： 1993 年美國國防部出資，由 Len Bass、Paul Clements 和 Rick Kazman 提出，由 SEI 發佈0
• ATAM (The Architecture Trade-Off Analysis Method)： 1998 年由 Paul Clements、
Rick Kazman 和 Mark Ctein 提出，由 SEI 發佈。
• CBAM (Cost-Benefit Analysis Method)： 1993 年美國國防部出資，由 Len Bass、 Paul Clements 和 Rick Kazman 提出，由 SEI 發佈。
• ARID (Active Reviews for Intermediate Designs)： 1998 年由 Paul Clements、Rick Kazman和MarkClein提出，由SEI發佈，用於評審架構構建初期或架構半成品的評審技術。
• SPE (Software Performance Engineering)： 1995 年由 Smith and Williams 提出。
• PASA (Performance Assessment of Software Architectures)： 2002 年由 Smith 和Williams提出。
• RMA (Rate Monotonic Analysis )： 1993 年由 Klein M 和 Ralya T 等人提出。
• SAAMCS (SAAM Founded on Complex Scenarios) ： 1999 年由 N .Lassing 提出。
• SAEM(Software Architecture Evaluation Model )： 1998 年由丄C.Duenas 等人提出。
• SBAR (Scenario-Based Architecture Reengineering )： 1998 年由 P.O.Bengtsson等人提出。
在這些架構評審方法和評審技術中，有些是針對當前尚未一個完整的系統架構的情
況選用的評審技術，例如ARID (Active Reviews for Intermediate Designs)方法：有些是 評判當前架構中所採用的架構方法或架構設計抉擇，例如CBAM (Cost-Benefit Analysis Method)方法：若是要求專門進行某種特定的質量要求（例如Performance)，則能夠採 取 SPE (Software Performance Engineering), RMA (Rate Monotonic Analysis)等評審方法•
與此同時,還有大量的研究工做圍繞着這些方法和技術展開。例如Dobrica和Niemela 共同進行的研究是對目前幾種主要的評審技術進行透徹的分析和對比，他們的研究報告詳 盡地闡述了各類架構評審技術的優缺點。經過此項研究成果，很大程度上幫助咱們選擇適合自身評審狀況的評審技術。
若是從實戰角度上來說，目前各類機構或公司（諸如美國國防部、美國航天局、AT&T、 Nokia、Siemens、Lucent等）使用最爲普遍的主要是下述三種主要的評審方法：「基於問卷、 場景和度量技術的混合型架構評審方法」、「基於問卷/檢查表技術的提問式架構評審方法」以 及「基於問卷/檢查表和度童技術的混合型評審方法」，下面咱們對其進行逐一詳細講述。
方法一：基於問卷、場景和度量技術的混合型架構評審
當前，業界很是盛行參考應用基於場景技術的架構評審方法。其中，最爲經典的莫過 於著名的ATAM架構分析和評審方法（雖然ATAM標榜本身是基於場景和度童技術的混合 型評審方法，可是ATAM仍是以其擅長場景技術而著稱)。咱們能夠參見SEI公佈的ATAM 概念模型圖，如圖6-4所示。
若是從評審流程的角度上來說，ATAM評審方法主要包含四個重要的階段和九個核心 流程活動。現實中各個機構和公司架構評審實踐過程時，在參考ATAM主要流程及活動的 基礎上，也會或多或少地進行優化和改良，這主要體如今與問卷評審技術和度量評審技術 的結合上。目前應用ATAM進行評審時，大多會遵循如圖6-5所示的流程和主要動做。
Phase 0：準備階段(Partnership and Preparation)
此階段是評審啓動前的準備階段。該階段的主要任務是架構評審人員經過電話或 E-mail,與客戶方的一些主要的Stakeholders進行初步的溝通。這種溝通的主要目的以下：
•首先，使客戶方理解評審的大體過程及所使用的手段。
*其次，使評審人員明確須要進行評審的是什麼樣的系統以及一些系統相關的重要背
景信息。
•經過溝通，與客戶方造成正式的評審協議。
•評審方組織造成評審團隊，客戶方預定Stakeholders及相關架構、設計和編碼人員
的時間。
Phase 1 ：初始評估階段(Initial Evaluation )
從這個階段開始，就正式進入架構評審的執行階段。該階段的主要任務是與那些有技 術背景的Stakeholders進行交流，幫助評審人員深刻分析和整理系統全局範圍內那些最爲 重要的、Stakeholders最爲關注的、須要系統高質量併合理應對的場景。Initial Evaluation階段會包括以下六個主要的核心活動。 ‘
①介紹ATAM評審方法：向Stakeholders介紹ATAM方法所須要進行的步驟和動做、 評審中使用的技術（例如Utility Tree技術（效用樹）、架構方法和手段分析技術、場景頭腦風暴技術 等）以及評審結束時相應的產出物（例如應對質量問題所使用的架構方法、Utility Tree、 排定優先級的場景、威脅或敏感點等）。基於這樣全面的介紹，爲整個架構評審設定目標並 展現預期的結果，從而與Stakeholders的認知達成一致。 ：
②介紹系統背景信息：客戶表明向評審人員介紹該系統開發的主要商業背景和商業目 標。這包括系統商業運做背景、最高層面的系統功能需求、最高層面的質童要求（例如系 統架構構建時期須要考慮的質量因素、核心重點關注的質量要求等)。經過這樣的系統背景 介紹，評審人員和全部Stakeholders對系統存在的大背景有了一個完整的認知-
③介紹系統架構和設計：一般由系統總架構師來給評審人員和Stakeholders全面介 紹當構和設計。這能夠包括最高層面的系統架構概念（例如操做系統、硬件、 中間件:‘、通訊網絡等）、該系統與其餘遺留系統的集成交互概念、架構中爲了保證質量所使 用的重要方法和手段（例如架構原則、架構風格、設計模式等)、重大的架構及設計抉擇點 (例f用第三方產品）、利用一些重要的質量要求場景來推演系統架構的實現能力、利用一些重要的發展演化場景來推演系統的適應能力、其餘相關已經識別出的威脅或Open Issues等。這樣全面的架構介紹，在很大程度上可以幫助評審人員探索和捕捉一些須要深 入驗證和評審的問題。同時，全面的系統架構介紹在很大程度上促進了系統研發團隊與其 他Stakeholders在系統當前進展狀況上的認知一致。
④識別架構中保證質量的方法：系統總架構師進行的系統架構和設計介紹每每涵蓋了 比較抽象層面的概念，可能從細節的程度上講還不夠深刻。爲了更加詳細地識別整個架構 中保證質量所使用的方法，評審人員須要在架構組成員的幫助下，進一步識別架構中所使用的那些重童級方法。這包括爲什麼使用3層架構風格、爲何使用watchdog和 publisher-subscriber設計模式、爲什麼使用硬件熱備份這樣的冗餘方法等這種識別的結果， 在很大程度上幫助評審人員理解了實現那些重要質量要求的架構方法。而且，評審人員的 腦海中已經清晰完整地創建了系統核心基線架構。
⑤建立質量Utility Tree（效用樹）：通過前4個活動，評審人員已經明確了系統實現的總目標以 及架構人員是如何構建該系統架構的，並在必定程度上造成了完整的系統架構概念。可是， 直到目前爲止，評審人員只是看到了當前的架構和設計，並收集整理出了一份有關係統應 該實現的質量要求詳細清單。
第5個核心活動的主要目的，就是在該項目決策層（例如客戶表明、職能經理、架構 組）的幫助下，識別和提煉出那些最爲重要的質量要求及指標參數，並根據重要性和實現 的難度排定優先級。因爲架構評審畢竟只有爲數很少的幾天時間，不可能在全局範圍內對 任何細節質量要求進行全面的評審。在實踐中，通常公司會主要針對最爲關切的質量進行 分析和提煉。
建立質量Utility Tree活動是架構評審中極爲重要的一個活動。該活動的完成質童直接 影響了評審的質量。在進行該活動時，通常採用構建Util丨ty Tree和分解爲場景這樣兩個重 要的技術。
所謂的Utility Tree，是一個樹狀自頂向下結構的質量要求體系。Utility Tree的根能夠 命名爲「Utility」，其下面的樹枝通常是通用的質量要求，如Performance、Modifiability. Security、Availability等。再往下就是系統特定的那些質量要求，如數據的延遲、資源使用、 軟件出錯、硬件或CPU替換等。底層的葉子就是那些識別和分析出來的場景（scenario)。 請參見如圖6~6所示的一個Utility Tree例子。
Utility Tree 的最終產出是一些諸如 「Reduce storage latency on customer DB to < 200 ms」 和 「Network failure detected and recovered in <1.5 minutes」 等這樣的場景a 在 utility Tree的識別中，這些場景主要是在評審組的啓發下，由架構評審人員和項目決策人員共同完成。
識別Utility Tree中的場景主要遵循如下幾個原則:
•必須是Stakeholders最爲關切的、或者對系統架構有震撼性的那些質量要求。
•必須是完整、清晰、精準地表達了一個特定質量要求的場景。這包括誘因、背景、 應對的要求。
•蒐集和識別的場景應該考慮系統正常使用的情節。例如：遠端用戶在正常工做時間 經過Web方式要求從系統數據庫產生一張報表，時限不能超過5秒。
蒐集和識別的場景必須考慮系統正常演化所帶來的變化情節。例如：在將來增長一 個貨幣轉換的系統功能模塊，須要三我的天的工做量。
•蒐集和識別的場景必須考慮系統處於非正常狀況下（例如異常的流量壓力、主服務 死機）的情節。
建立質量Utility Tree的最後一個工做，就是根據場景在項目決策人員和其餘 Stakeholders眼中的重要程度，並結合架構人員承認的實現難度，對每一個場景打分或定級 (一般能夠考慮以10分制的打分方式，或以High、Medium、Low來定級），這樣就會出現 「Add CORBA middleware in < 20 person-months」，場景的定級爲（H, H)。經過完整的Utility Tree中所包含的各個場景的定級，咱們就能夠對全部的場景排定優先級隊列。
⑥分析實現重要場景的架構和設計方法：從活動4中咱們己經識別和彙總了那些爲架 構構建所應用的方法和架構與設計抉擇。第5個活動中咱們經過識別、彙總，排定了那些 優先級較髙的質量要求的場景。從如今開始，評審人員須要在架構人員的幫助下，開始映 射和分析這些彙總的信息。
首先，評審人員會經過分析，映射出具體的質量要求場景是由哪些架構方法或架構與 設計抉擇來完成的，在實踐中，這須要架構人員在評審人員的指導下進行，並最玫造成映射表。 '
其次，針對優先級高的每項場景和相應採用的架構方法，評審人員須要結合自身經驗 或技術領域經驗（這裏的領域是指實時系統領域、嵌入式系統領域等），事先準備好問卷， 對架構人員進行訪談。
架構人員面對場景和評審人員的一連串問題，詳細解釋採起目前架構方法和架構與設 計抉擇的理由。必要時，架構人員可使用相應的測試數據、模型推演、原型驗證或模擬 工具來代表本身抉擇的論證明際過程。
問卷和回答的形式最終會導致使討論的展開，從而幫助評審人員就每一個架構方法和架構 設計抉擇蒐集相應的 SWOT (Strength、Weakness、Opportunity、Threat),從而造成如圖6>7所示的架構方法和架構設計抉擇分析表。
架構評審的Initial Evaluation階段，主要執行了上述六個主要動做。到如今爲止，評
審人員、主要Stakeholders、項目決策層、系統架構人員都已經有了全面和系統的質童實 施體系的認知。
從上述六個流程活動來看，雖然基本上遵循了 ATAM中的瀑布式流程動做，可是-般 實際評審的過程每每與ATAM的流程有所不一樣，還須要對ATAM的操做進行調整並使之成 爲一個按部就班和迭代的過程。
•首先，爲了彌補活動1〜活動4的不足，評審人員一般會參考一些客戶方提供的架構 文檔，做爲交流理解的基礎。而後利用事先準備好的問卷與Stakeholders進行交流， 再反過來進一步理解架構文檔.這樣能夠有效地提升活動4(識別架構中保證質量 的方法）的工做效率。在進行活動5的工做時，甚至會參考一些商業信息做爲重要 的評審輸入信息。例如：參照商業信息中有關功能的路線圖和財務計劃，最終肯定 將來會發生什麼樣的系統級變化。
•其次，活動4~活動6的工做在實際操做中也是一個迭代的過程。通常會採用與 Stakeholders和架構人員按期會議的機制，逐步澄淸系統架構中的方法和抉擇，逐 漸淸晰重點質量場景，最終逐步完善活動6的彙總信息。在實際評審中執行這樣操 做，其實緣由很簡單：現實中的架構人員不可能一次性把你想知道的架構方法和架 構設計抉擇完整地告訴你；反而當你告訴他們客戶的質量要求場景時，會提醒他們本身先前爲解決這樣的場景所運用的架構解決方法。與此相相似，Stakeholders也 不可能一下就把本身的質量要求和質量場景想得那樣清楚、全面而詳盡，也須要反 復屢次地溝通和澄清，有時甚至是在評審人員和架構人員的提示和引導下， Stakeholders纔會明確表示「系統性能要保證500個併發用戶正常訪問服務器時， Web頁面的顯示時間不能多於5秒」這樣詳細的質量場景描述。
•最後，在活動6操做時，大量採用「問卷」這種有預先準備的提問式技術對架構人 員進行提示和引導。若是隻是採用傳統的ATAM方式進行開放式的討論，就會致使 經驗式的工做方式。尤爲是當評審那些重大架構設計抉擇和方法時，每每是在評審人 員的引導下，須要架構人員運用「度量技術，，提供試驗、模擬等方面的證據，而不只 僅只是由架構人員說，或者只是看看文檔後憑藉評審人員自身的經驗進行端測•
Phase 2：全面評估階段(Complete Evaluation)
全面評估階段（Complete Evaluation)主要有兩個目的：首先，以Stakeholders的質 量要求爲中心，最大程度地讓全部的Stakeholders參與進來，檢查、修正和補充Phase 1 階段的質量Utility Tree:其次，用Phase 1階段活動6造成的架構方法和架構設計抉擇分 析表來推演和驗證架構人員前期架構構建的工做，是否知足了全部stakeholders的那些重 要質量要求場景。全面評估階段Complete Evaluation是一個評測架構質量的階段，一般 有以下三個核心活動：
①頭腦風暴和場景優先級排定
頭腦風暴和場景優先級排定在整個評審過程當中很是關鍵。項目決策層召開一個架構評 審中最大規模的會議，要求全部的架構評審人員和全部的stakeholders到場，例如系統出 資方、最終用戶表明、架構方、系統服務管理方、系統實施方等全部系統相關人員.
會議首先會由評審人員介紹一下ATAM評審方法步驟，接着架構人員會簡單介紹一下 目$系統架構的狀況。而後，評審人員會將前期總結提煉出的質量utility Tree給參會人員 進行詳細的解讀。質量Utility Tree會成爲Stakeholders關心的一個重點，由於這正是他們 要求的質量點。同時這也是一個啓發思路的步驟，爲後續的頭腦風暴作好了鋪墊。
接下來，評審人員會要求Stakeholders進入頭腦風暴的過程。基於目前的質量Utility Tree的啓迪做用，鼓勵每一個Stakeholders提出本身所關心的那些質量場景（不管這些場景 是否已經包含在目前的質量Utility Tree中）•這些場景與評審人員初創質量Utility Tree時 相仿，要求涵蓋了系統正常使用的情景、系統正常演化所帶來變化的情景、系統非正常情 況下的情景等。
通過一輪頭腦風暴’評審人員己經蒐集到不少的質量場景。接下來，就進入質量場景 優先級的排定過程。每一個Stakeholders會分到質量場景總數30%的選票，例如咱們共蒐集 了 24個質量場景，那麼每一個Stakeholders就會獲得8張選票，而後，Stakeholders可將 選票投給本身認爲最重要的30%的質量場景。通過統計後，全部的質量場景就會獲得一個 優先級的排序。經過這樣一個收斂和排序的過程，咱們會逐漸聚焦在那些最須要關注的重 要質量場景上，這是關鍵需求，也是評審的重點。
而後’在評審人員的引導下，將這些排定優先級的質量場景按照質量類別屬性，放在 質量Utility Tree中相應的位置。在大多數狀況下，Stakeholders的質量場景己經被架構人 員在Utility Tree中所涵蓋。可是’經過此次頭腦風暴，也會發現有些Utility Tree中的場景 表述得或許不許確甚至不對。固然，有可能個別的一些質量場景以前並無被UtilityTree 所考慮，這正好是對架構工做的一次檢驗和修正。
通過這樣一輪質量場景頭腦風暴，如今評審人員手中的質量Utility Tree就已是一個 完整的、被各方承認的、具備權威架構約束力的質童需求文檔。這個完整的質量utility Tree 是咱們架構評審最重要的結果之一。
②分析實現重要場景的架構和設計方法
質童場景頭腦風暴會議介紹結束後，評審人員須要和架構人員坐在一塊兒，對utility Tree 中那些新增長的或修改的質ft場景，逐一進行Phase 1階段活動5的動做，即分析當前系 統架構中爲了實現這些場景而使用的架構方法、架構設計抉擇。最終造成的分析結果則是 架構構建徹底匹配上Stakeholders全部的質量要求。該分析結果也成爲最終版本的評審結果之一•
③展現評審結果
第二階段的最後一個動做，就是要將這次的評審結果給Stakeholders作一次展現和介 紹，使各方都能看到最終的評審結果信息。展現的評審內容包括：
•質量 Utility Tree。
•排序後的質童場景。
•架構方法、架構設計抉擇。
•架構中存在的 Strength、Weakness、Opportunity、Threat。
Phase 3：跟進階段(Follow up)
架構評審結束後，須要向客戶提交一份正式的書面評審報告。因爲通常是管理職能經 理來看這份正式評審報告，他們通常但願看到評審是如何進行的、最終發現的問題、有哪 些威脅以及相應的改進機會，因此不能只是將評審過程當中的文檔進行簡單彙總，還須要一 定的提煉。
做爲職業評審人員，架構評審還應該向客戶發一份調査問卷，以幫助評審方瞭解客戶 對這次評審的滿意程度及相應的意見和建議。
最後，這次評審的全部過程性文檔須要存檔保存，以便於往後的統計和複用。
方法二：基於問卷/檢查表技術的提問式架構評審方法
基於問卷/檢查表技術的架構評審方法是另一種比較流行的、相對簡單實用的評審方 法.許多機構和公司都有本身的架構評審問卷或檢查表（就如同不少公司有本身的CMMI 評審問卷同樣，不過這些問卷大可能是保密的）。這種評審方法與Bosch J提出的經驗式架構 評審很是類似，即以公司或機構的高級架構師、高級技術顧問的架構實踐爲基礎，結合領 域內的經驗總結出來的問卷和檢查表„這裏所談到的領域經驗，主要是指實時系統、嵌入式系統、電信系統、航空系統等專業領域。
正是因爲上述緣由，問卷/檢查表的架構評審方法通常被大量地應用在行業特徵明顯、 系統狀況相對固定的機構或公司裏。例如工業自動化系統的開發公司，每一個項目所產出產 品的應用領域都是工業自控方面的系統，而且其使用的底層硬件相近，選擇的操做系統相 似，控制原理和控制邏輯也相仿。再例如車載系統的生產公司•絕大多數產品都是嵌入式 系統，面臨的技術問題相近，須要克服的質量問題也大體相仿。這些領域的公司每每喜歡 用問卷/檢查表這種經驗式的、可複用的架構評審方法來評價一個系統的架構。
相比而言I問卷/檢查表式的評審比基於場景的評審方式更簡單，基本上由如圖6-8所 示的五個核心活動組成。
1.肯定評審範圍
問卷/檢查表的架構評審方法通常是公司和機構對系統全局範圍內的狀況進行的—種 評估式評審。因此，一般會要求評審所覆蓋的系統架構更爲全面。這就形成問卷/檢查表的 評審範圍一般比基於場景的評審範圍要廣„與基於場景的評審方法類似，問卷/檢查表的評 審也須要強調一些重點’進行深刻細緻的評判。例如：這些重點能夠是stakeholders所擔憂的可擴展能力，也能夠是架構組所擔憂的容錯能力。
架構文檔及系統相關技術、商業文檔的收集也是在這個活動中初步完成。後續文檔的 蒐集須要在評審進行中逐步挖掘整理。
2.分析架構文檔
與基於場景的架構評審不一樣的是，在面對被評審方以前，要求架構評審人員仔細閱讀 和分析現有的架構文檔及其餘技術支持文檔。這樣作的益處在於：首先，評審人員在文檔 的幫助下，不受外界影響，獨立構建出系統架構的初步概念：其次，有效評審了系統架構 文檔的質量：另外，使後續的評審更有側重性，便可以帶着分析架構文檔後的重點疑問進 行後續的評審工做。這樣作雖然有不少優勢，可是對評審人員的架構經驗要求很高。
3.選擇面談人員
問卷/檢查表的架構評審方法在進入評審動做前，須要嚴格選擇面談對象。面談對象選 擇的質量，會嚴重影響評審的質量。面談的人員通常能夠劃爲下述三種類型：
•系統需求相關人員：與系統功能和非功能性要求相關的人員。這能夠包括系統出資 方、終端用戶、需求工程師、各類職能經理等需求責任人。
•系統架構相關人員：系統總架構師、子系統架構師、高級技術經理等負責系統架構 的責任人。
•系統開發人員：高級程序員、技術專家、業務專家、系統測試等負責具體方面（例 如負責性能方面、負責安全機制方面等）的責任人。
面談對象選定後，須要提交項目決策層，並由他們負責安排面談時間。須要說明的是， 當前選定的面談對象每每不是固定不變的，在實踐操做中咱們就會發現，咱們面談的對象 每每會不斷增長’一般是由當前選定的對象逐步推薦而添加進面談對象的隊列當中。
4.進行面談
面談對象選定後’在與每一個面談對象進行面談前，還須要根據面談對象的不一樣而準備 不一樣的問卷。這個步驟是整個架構評審中很是關鍵的一個動做。咱們能夠參考下面問卷目 錄的一部分來總結本身的問卷。
1. Requirements
2. Analysis & Design
3. Testing
4. Re-factoring
5. Object-Oriented Design
6. Introduction of new colleagues/contractors
7. Operating System
8. Threading
9. Communication
10. Error-Handling
11. Startup/Shutdown
12. Resource Management/Memory Usage
13 Performance
14. Stability
15. Shared HW Resources
16. Software-Hardware Integration
17. Real-time Constraints
18. Embedded Constraints
19. Constraints imposed through distribution
20. Evolution of existing architectures
在準備問卷時，還須要將評審人員所靠握的相應質量要求和分析出的問題結合進問卷。 舉例來說，若是咱們今天面談的對象是負責實時性(Real-time)要求最髙的子系統架構師 時，咱們的問卷可能會是下面這樣。
1 . Do you have timing constraints in your system (list these)?
2. What are those time-constrained actions?
3. Which actions are sporadic and which ones are periodic?
4. What is the time constraint of each action?
5. Are these actions independent of each other?
6. What is their dependency structure?
7. How should the system react in case of an action missing its time constraint?
8. Is it possible/reasonable to keep all time-constrained actions on a single CPU?
9. Is there any communication between several time-constrained actions?
10. Are there any non real-time activities in your system?
11. What are those activities/scenarios/requirements?
12. Is there any GUI involved which allows to operate the system?
13. Do you have to meet any integration with other systems (ERP: Enterprise Resource Planning like SAP, Web)?
14. Are there any future requirements related to this kind of integration?
15. Is there any interaction/message exchange of such activities with time-constrained actions?
進行面談時，首先要求評審人員向面談人員申明這次談話只會記錄相應的事實，而不 會記錄這些事實是由誰提供的，這樣能夠打消面談人員的政治壓力。接着，以這些有針對 性的問卷爲開始，引導面談人員的思路並最終造成經驗交流和探討式的談話，這樣很容易使面談人員逐漸放鬆情緒，可以就係統的顧慮、擔心、意見、建議等進行開放式的交流， 最終造成良好的合做。
在面談中，常常會遇到有些不屬於面談者職責範圍內的問題，或者面談者沒法提供相 關的細節。這時面談者能夠爲評審人員指定熟悉相應狀況的其餘人員來補充信息•天然， 面談人員的列表上不能遺漏本次訪談的補充面談者，
每次面談結束後，須要根據記錄的筆記對本次面談獲取的信息進行整理，提升信息的 完整性和條理性。
5.分析和報告
當既定的全部面談結束後，評審人員須要在評審組長的帶領下，再次結合前幾個步騍 中獲取的需求、架構和技術文檔等信息，結合面談時暴露的問題，進行更加細緻的分析. 這樣作的目的就是將捜集到的問題進行進一步的考證和彙總^該分析工做是按部就班的過 程，常常是在面談進行的同時就能夠展開^這是一個工做量比較大、線索複雜的過程》這 與基於場景的評審方法有着很大的區別。
問卷/檢查表式的評審方法在分析結束後，要爲Stakeholders展現最終的評審結果並向 客戶提交一份正式的評審報告。固然，後續的客戶滿意度問卷、評審歸檔的動做是不可缺 少的，這與基於場最的評審沒有什麼區別.
須要說明的是，利用問卷啦查表式的技術進行架構評審，須要的時間每每比使用場景
的技術多不少。主要緣由是問卷查表技術要求覆蓋的面很廣、須要有面談人、須要進行 分析’是一種系統全方位權衡的評估方法•而基於場景的評審，每每是集中在一些主要核 心需求上的架構評審（ATAM評審最初是針對系統演化所帶來的變化而研究的一種架構評 審技術)，這與問卷/檢查表技術有着很大的區別。另外，因爲時間的限制，問卷/檢查表技 術所能評審到的架構深度，沒有場景技術的評審那麼深刻„
方法三：基於問卷/檢查表和度量技術的混合型評審方法
問卷/檢查表和度量技術這種混合型的評審方法,其實就是爲了彌補單純問卷/檢查表技
術深度的不足而產生的。目前應用這項評審技術的公司也很是多，尤爲是美國國防部、 Nokia、AT&T等那種恃定的系統/產品生產開發機構。它們研發特定領域的系統，並對特定 質量要求很是高（例如系統可靠性)。
問卷/檢查表和度量混合評審，在過程上與單純的問卷/檢查表基本一致。不一樣點在於:
•肯定評審範圍階段，主要是與Stakeholders肯定評審重點，例如：Performance。
這與全面架構評審的單純問卷/檢查表評審方式截然不同。
•面談對象也選擇那些與評審重點相關的人員。
•面談過程當中，不僅僅使用問卷/檢查表技術’一般會大量結合指標（例如性能指標） 制定模擬計劃，進行模擬並彙總模擬結果，從而爲問卷提供充分的證據。
雖然咱們對當前流行的架構評審方法和評審技術進行了探討，但在實踐中不少狀況其 實是要求咱們混合使用各類評審技術來完成評審工做。沒有哪種評審技術既全面，又深 入，而且代價小„這就要求咱們根據自身面臨的狀況，選擇一種或幾種合適的技術來進行評審。這與進行系統架構抉擇的過程相仿，也是一個折中妥協的過程
6.5架構評審輸出彙總
儘管咱們能夠選擇的評審方法和評審技術不少，可是每種架構評審方法最終都須要相 應的評審輸出結果。從架構評審的效果上來看，一個評審每每能夠增進stakeholders間的 溝通、提升架構文擋的質量、增長架構人員對質量需求的全面而細緻的理解並增進客戶對 系統架構抉擇和妥協緣由的認同。
做爲一個架構評審的有形的、必需的結果，通常都須要準備一份相應的評審報告，來 陳述架構評審的發現和建議，從而爲決策層提供相應的決策支持。在實踐評審工做中，我 們能夠參考使用下述相似的評審報告模板：
1.評審目標。
2.評審範圍和重點。
3.評審方法。
4.評審參與人員。
5.系統架構介紹。
6.系統質量要求。
7.系統架構方法及架構抉擇彙總。
8.評審採用的度量指標。
9.當前架構的優勢。
10.評審中的發現。
11.識別的問題和威脅。
12.評審方和被評審方的建議。
13.改進計劃。
14.其餘相關發現。
6.6架構評審實踐指導
雖然咱們已經比較清晰地瞭解了架構領域內一個重點研究方向：架構評審的發展和相 關評審技術。可是現實中作好一個系統架構的評審並非一件簡單的事。須要在實際的評 審的過程當中不斷進行總結。有了鋒利的刀，並不必定就能作個好戰士。
在實際的架構評審中’咱們或許在不一樣的評審操做階段會碰到一些各類各樣、提早沒 有預料或者難以解決的問題。下面咱們列舉了一些實踐中可能遇到的問題，並提供了一些 應對方案和思路供讀者參考。
1.評審目標肯定階段
問題：咱們接到一個從客戶方的質量管理經理處傳來的架構評審請求•可是很是不幸， 該質量管理經理說不淸本身的目的是什麼，只是說對目前的系統架構心中無數。
方案：必須在評審開始前.與各個重要的Stakeholders或其表明進行一個預備會議， 或者以單獨走訪的形式（不用會議這樣正式公開的形式）拜訪幾個最爲重要的 Stakeholders, 目的是澄淸評審目標，不然應該拒絕這樣的評審請求#
2.評審準備階段
問題：爲了有效地進行評審，必備的架構文檔是評審的一個成功約束條件.伹是，經 常獲取的架構和技術文檔並不充分。更爲嚴重的是，有些架構根本沒有文檔。即使有，其質量對評審也沒有什麼幫助。
方案：請相關的架構人員使用presentation的形式來說解其構建的架構，以後進行一 輪Q&A,以便於評審人員和架構人員對架構的認知達到相同的水平。
3.評審進行階段
問題：評審進行時，發現架構人員等相關技術人員對你有明顯的抵觸情緒，由於他們 認爲你是管理決策層派來檢査他們工做的•
方案：首先，評審人員必須尊重這些技術人員•也許評審人員的架構經驗更爲廣博和 精深，可是，這些技術人員比評審人員有更強的商業領域經驗•因此，不能以一種挑剔和 批評的態度進行評審，應該抱着結合他們的長處與自身的經驗共同探討的評審態度，最好 把本身認爲是架構組的成員之一•其次，在任何狀況下，不要向客戶管理層報告某某人拒 絕配合評審。同時，可讓管理層與那些拒絕合做的人進行溝通並說服他們進行更好的合 做.若是出現最差的狀況，那就繞過這些拒絕合做的技術人員，找其餘能夠代替的人進行 評審。
4.評審分析和評判階段
問題：進入分析和架構評判階段，因爲商業領域、技術領域經驗的侷限，評審人員很 難對當前的系統架構給出一個適當的評判。
方案：主要依靠自身的經驗來感受。首先，通過了評審的過程，評審人員或多或少已 經對系統架構有了「感受」。這不是說依靠我的情感來感受系統架構的好壞，通常須要有一 些前提證據存在，例如：該公司的老架構師每每比較值得信賴，能夠參考他們對系統中使 用的架構方法、架構及設計抉擇的緣由的合理解釋，來「感受」該系統架構，從而得出自 己的評判。若是可能的話，有時也可使用對比法來比較當前的系統架構和先前該公司其 他相似項目的架構，從中找到評判依據。
5.評審結果展現階段
問題：評審結果展現應該是開一個大會展現給全部的Stakeholders,仍是劃分不一樣的 組分別展現？若是不能造成一個全部Stakeholders參加的大會，該怎麼辦？
方案：首先，要儘可能開一個大會，把評審結果一次性地給全部Stakeholders公開、正 式、明確地展現出來。若是不能造成大會形式，最好將評審結果展現給評審發起者或出資 者.而後分組安排時間來展現評審結果。這樣作的目的很明確，就是要讓全部的 Stakeholders知道評審結果，
通過幾回評審實踐，咱們就會發現_些先前從沒有遇到過的各式各樣的問題。其實， 架構評審不僅僅是一個技術工做，它同時也如同一個臨時性的小社會，會存在各類社會、 心理、利益上的現象。
雖然系統架構評審做爲一項流程和技術只是短短地發展了十幾年，可是己經獲得越來 越多公司和機構的認同。畢競系統架構是一個複雜的過程，利用第三方來驗證系統架構的 質量，是一種保證系統自己質量的有效手段。截至目前，雖然己經有一些評審實踐方法和 技術能夠參考，可是並無造成一套統1、標準、通用的評審方法^不一樣的領域須要根據 自身的狀況，選擇適合本身的評審技術並不斷地完善它。