軟體架構評估指導書

 1.概述
     我們常說軟體架構是軟體項目取得成功的關鍵要素。那麼什麼是軟體架構呢？SEI認為一個程式或電腦系統的軟體架構是指此系統的一個或多個結構，一個系統包含多個組件以及這些組件的外部可見屬性和各組件之間的關係。“外部可見”屬性是指其他組件使用該組件時的假設，如它提供的服務、效能特徵、錯誤處理、共用資源的使用等。
     通俗意義講，軟體架構，就如同建築圖紙一樣，它規划了整個建築的架構。軟體架構是軟體的設計藍圖，是軟體的體繫結構，它把軟體的各個部分通過約定的契約（介面）有機的組合起來，形成整體。
     架構如此重要，那麼確保選擇和設計正確的架構也變得更加關鍵。架構評估是一種產品的驗證形式，就像軟體測試是一種代碼驗證形式一樣。架構評估可以在不同階段不同時期進行，它可以在規劃架構或權衡候選架構時（即選擇技術備選方案）時進行，也可以在初步的架構決策完成之後詳細的設計開始之前進行；評估也可以在整個系統建立之後進行，此時主要是進行再工程或資產挖掘。架構評估的輸出依賴於所執行的階段。
     必須指定足夠的設計決策以便於分析需求和品質屬性目標的實現。架構的決策制訂的越多，越能精確的執行評估。但另一方面，決策制訂的越多，越難以更改。

     2.工作流程
     2.1確定架構評估方向
     評估架構需要選擇評估的要素，明確評估的關注點。例如：關注品質還是進度。誠然，品質和進度都是SE應該關注的，但在實際操作過程中，往往需要在品質或進度之間做出取捨。如何平衡兩者之間的關係，是SE的職責之一。通常意義將，市場緊迫意義強，屬於搶佔市場型的產品，往往要在品質上做出一定的犧牲，軟體架構以能滿足當前需要為出發點；而那些屬於長期型、需求不穩定、產品可塑性較大的產品，關注架構品質更具有意義。

     2.2明確架構需要滿足的行為需求和品質目標
     系統的營運目標導致了特殊的行為需求和品質屬性目標。評估前必須明確架構支援那些行為和品質屬性目標，以及這些品質屬性目標支援那些營運目標。例如：如果營運目標是系統將長期存在，可維護性就是一個重要的品質屬性目標。必須將重要的品質目標具體化，也就是說品質目標必須具有可衡量性，架構評估必須提供可以參考的證據。架構評估必須考慮風險的影響，任何一個評估要素如果風險等級為高，則該評估要素必須予以重點關注。

     2.3選擇架構評估要素
     選擇架構評估要素之前，要明確架構的利益相關者；明確技術方案的需求，選擇可以驗證的評估要素。例如：
     l 運行效率；
     2 資源佔用率
     3 可維護性
     4 可擴充性
     5 開發效率
     6 穩定性
     7 需求可變性
     8 可重用性
     與利益相關者共同確定架構關注點和要素，並尋求共同期望的目標。通常我們建議提供checklist，並提供明確的計分標準。也可以通過在checklist給出權重，評估者直接給出通過與否的建議。對於重要的評估要素，比如：效能等可以採取一票否決制。系統的架構代表了一組最早的設計決策，最難修改，同時也最難保證正確。品質目標要考慮 1）支援產品的品質目標；2）隨著時間的發展支援產品的預期發展。

     2.4選擇架構評估方法（軟體架構實踐）
     業界有很多架構的評估方法，介紹幾種常用的方法。 
     ATAM架構平衡分析方法（architecture trade-off analysis method，atam）
是一種基於情境的架構評估方法，重點考察系統的品質目標。它的輸出包括：
     一系列情境，表示利益相關者對此系統和架構最理想的用法和品質型目標。
     一顆工具書，將各個情境分配到被評估系統的架構所支援的各品質屬性。
     專業分析結構，包括對敏感點的顯示識別、折中方案和其他絕對或可能會影響所要求的品質屬性的架構據測。通常需要三整天以及一些準備和初步的調研時間。

    ARID中間設計的主動評審（active reviews for intermediate designs, arid）
是一種綜合了ADR主動設計陪你更深哲學和ATAM和SAAM中基於情境的分析方法的混合設計評審技術。它是在早期或概念階段業績在其完全文檔化之前建立的，用來評估部分設計。它的工作方式是為了設計召集利益縣官這，讓他們選擇一組能有效表達其使用設計方式的情境，然後通過代碼或微代碼通過設計實現每個情境。
     主動設計評估（active design reviews, adr）
     該技術主要用於正在構造的架構。它的原理是由利益相關者評審描述組件所提供的介面設計的文檔，但要求利益相關者完成所有練習，這些練習會強迫他們實際的使用文檔。

     2.5軟體架構實踐的選擇
     根據所處階段、目標等的不同選擇適用於自己的架構評估實踐。架構評估實踐的選擇表如下：

情境\方法	ATAM	ARID	ADR
階段
輸出
目標
範圍

     3.架構評估的風險
     錯誤的人員參加評估；參與架構評估的應該是架構的利益相關者和對架構有充分認識的人員。 

     架構的設計者完全主導評估；這個風險主要源於以下因素：
     A. 參與人員沒有足夠的時間瞭解；
     B. 參與人員不是技術人員，無法瞭解技術細節；
     C. 提供者過於強勢，掩蓋了所有不同意見；
     D. 不注重事實。
     3 對架構的風險估計不足
     4 風險較大或存在問題的要素沒有重新評估
     5 生命週期中的錯誤時間進行評估；例如：當編碼已經大規模開始，架構評估完全失去意義。
     6 沒有時間進行評估。
     7 對評估進行錯誤解釋。
     8 沒有資料支撐，僅憑一面之詞。