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 沒有資料支撐，僅憑一面之詞。
企業各部門基本管理職能分配（指導書）
成本管理 2008 01 29 12 12 32 閱讀789 字型大小 大中小 訂閱一 生產部門職能 1.生產計畫 2.作業計畫 3.作業令號 4.生產排程 5.生產準備 6.生產統計 7.生產記錄 8.均衡生產 9.文明生產 10.安全生 產 11.現場 環境管理 12.在製品 半成品的管理 13...
zigbee3 0學習筆記 開發指導書 裝置 位址
裝置 協議棧 配置檔案可以被修改，修改後稱為 stack specific stack profile 協議棧版本的識別符號在裝置傳輸的beacon中，加入網路之前確認協議棧 協議棧版本配置 stack profile id 在nwk golbals.h 檔案中 define network spe...
論軟體系統架構評估
2016年3月，我公司承擔了國家某安全中心漏洞挖掘系統的開發工作，我在該專案中承擔系統架構設計師的職務，主要負責系統的架構設計。該項目的主要目的是依託大資料平台從網際網路流量中挖掘未知漏洞。本文以漏洞挖掘系統為例，論述了軟體系統的架構評估。首先分析了軟體架構評估所普遍關注的質量屬性並闡述了其效能 可...