概述#

前面各章（Chapter 4-13）為十個核心品質屬性各自提供了通用情境、戰術、問卷和設計模式的完整組合。然而，現實世界中架構師可能遇到 任何 品質屬性需求——遠超過這十個。本章回答一個關鍵問題：當你面對一個沒有現成「戰術組合」的品質屬性時，該怎麼辦？同時也探討標準品質屬性清單的用途與局限性。

品質屬性的名稱本身幾乎毫無用處，充其量只是開啟對話的邀請。情境（scenario） 才是精確表達品質屬性需求的最佳方式。不要浪費時間爭論某個品質屬性歸屬於哪個分類——將精力投入在撰寫具體情境上。

其他品質屬性的類別#

書中已深入探討的十個品質屬性（Availability、Deployability、Energy Efficiency、Integrability、Modifiability、Performance、Safety、Security、Testability、Usability）並不能窮盡所有可能。以下依據衡量面向的不同，將其他品質屬性歸為數個類別。

開發專案相關的品質屬性#

這些屬性衡量的是 開發過程 而非系統本身的運行：

• Buildability（可建構性）：架構能否支撐快速高效的開發？以金錢或時間成本衡量。
• Conceptual Integrity（概念完整性）：架構設計是否一致？在具概念完整性的架構中，同樣的事情用同樣的方式完成——元件間的通訊方式、錯誤處理、日誌記錄、使用者互動、資料清洗等都遵循統一慣例。概念完整性帶來可理解性，減少混淆，提高實作與維護的可預測性。在概念完整性高的架構中，少即是多：例如元件之間的通訊有無數種方式（訊息、資料結構、事件信號等），但好的架構只會採用少數幾種，除非有充分理由才引入替代方案。
• Marketability（市場性）：架構本身的「品牌效應」。當前對雲端與微服務架構的追捧顯示，架構的 感知價值 有時與其實際品質同等重要。許多組織即使不一定是正確的技術選擇，仍感到必須採用當紅技術。

開發分散性（Development Distributability）#

開發分散性 是支援全球分散式軟體開發團隊的品質屬性。如同可修改性，此屬性以開發專案的活動來衡量。許多現代系統由全球分散的團隊開發，必須克服的核心問題是協調團隊活動。系統設計應使 團隊間的協調最小化——主要子系統應呈現低耦合。這不僅適用於程式碼，也適用於 資料模型。

• 被多個不同團隊開發的模組所使用的模組，其溝通與協商成本會更加複雜
• 架構結構 與 組織社會結構 需合理對齊（呼應 Conway’s Law）
• 相關情境關注的是：系統的通訊結構和資料模型與開發組織的協調機制是否相容

系統品質屬性（System Quality Attributes）#

對於內嵌軟體的物理系統（如飛機、汽車、廚房家電），還有許多不屬於純軟體範疇的品質屬性：重量、尺寸、耗電、功率輸出、汙染排放、耐候性、電池壽命 等。

• 軟體架構對系統品質屬性有深遠影響——低效的運算資源使用可能需要額外記憶體、更快處理器、更大電池，甚至額外處理器
• 反過來，系統的架構或實作也可能限制軟體達成品質需求——軟體效能最終受限於所運行的處理器能力
• 物理安全 在防止詐欺與竊盜方面，往往比軟體安全更重要且更有效

如果你是嵌入物理系統的軟體架構師，必須理解整個系統需要達成的品質屬性，並與系統架構師和工程師合作，確保軟體架構對這些屬性做出正面貢獻。用於軟體品質屬性的情境技術同樣適用於系統品質屬性。

架構本身的品質屬性（Quality Attributes of the Architecture）#

這一類品質屬性聚焦在衡量架構本身，而非系統運行或開發過程。前面提到的 Buildability、Conceptual Integrity、Marketability 皆屬此類。這些屬性影響的是架構作為一個設計產物的品質——它是否易於理解、是否能有效地轉化為實作、是否在市場上有競爭力。

使用標準品質屬性清單——與否#

ISO/IEC 25010 標準#

ISO/IEC FCD 25010 是一個廣為引用的品質模型標準，將品質屬性分為「使用品質（quality in use）」和「產品品質（product quality）」兩大模型。

產品品質模型列出八大品質特性：

• Functional Suitability（功能適合性）：產品功能在指定條件下滿足明示與隱含需求的程度
• Performance Efficiency（效能效率）：在指定條件下相對於資源使用量的效能
• Compatibility（相容性）：在共享硬體或軟體環境下，與其他產品交換資訊或執行功能的程度
• Usability（易用性）：指定使用者在指定脈絡中有效、高效且滿意地達成目標的程度
• Reliability（可靠性）：在指定條件下的指定時間內執行指定功能的程度
• Security（安全性）：保護資訊與資料，使人員或系統獲得適當存取權限的程度
• Maintainability（可維護性）：預期維護者修改產品的有效性與效率
• Portability（可移植性）：產品從一個環境轉移到另一個環境的有效性與效率

此標準進一步將這些特性分解為近 六十個子特性。例如 nonrepudiation（不可否認性）是 security 的子特性；modularity（模組化）是 maintainability 的子特性。標準中也做出了許多值得商榷的劃分：Usability 是產品品質而非使用品質，但其中包含的 satisfaction 卻是使用品質；Modifiability 和 Testability 都歸屬於 Maintainability；Availability 歸屬於 Reliability；而 Scalability 完全未被提及。

標準清單的價值#

標準清單（以及各種流通的品質屬性列表）確實有其用處：

• 可作為 需求收集的檢核清單，確保沒有遺漏重要需求
• 更有用的做法是以此為基礎，建立你自己的領域、產業、組織或產品的 客製化清單
• 可作為建立量測基準的起點（儘管名稱本身幾乎不提供如何量測的線索）

標準清單的局限#

• 永遠不完整：架構師必然會遇到任何清單都未預見的利害關係人需求。例如「manageability（可管理性）」——系統管理員管理應用程式的難易度，可透過插入有用的監控和除錯工具來達成。書中更提到一個真實案例：某美國中西部組織的架構目標之一是 「Iowability」——透過引入尖端技術和給予開發團隊創意自由，來留住關鍵員工並吸引人才到該偏遠地區。這個品質屬性在任何標準清單中都找不到，但對該組織而言至關重要。
• 製造爭議多於理解：你可以爭辯「functional correctness」應屬於「reliability」，或「portability」只是「modifiability」的一種，或「maintainability」是「modifiability」的一種（而非反過來）。ISO 25010 的制定者顯然花了不少時間決定將 security 從 functionality 的子特性提升為獨立特性。這些爭辯的精力可以更好地用在其他地方。
• 分類法的假象：清單常號稱是分類法（taxonomy）——即每個成員只能歸入一個位置。但品質屬性本質上彼此重疊。例如 denial of service 同時涉及安全性、可用性、效能和易用性。如果「fun（趣味性）」是你系統的重要關注點，你又該如何量測它？

標準清單的最大風險是讓人誤以為有了清單就不需要深入分析。請將清單當作有用的檢核工具，但不要盲目遵循其術語或結構，更不要以此取代對情境的深入探討。

處理「X-Ability」：將新品質屬性納入體系#

假設你是架構師，必須處理一個沒有現成知識體系的品質屬性——不像 Chapter 4-13 那樣有完整的「組合」（通用情境、戰術、問卷、模式）。無論是 development distributability、manageability 還是 Iowability，你都可以依循以下三個系統化步驟來將其納入你的架構決策框架。

第一步：擷取情境（Capture Scenarios）#

第一步是訪談那些因關切而引發此品質屬性需求的利害關係人。你可以與他們個別或集體合作：

• 建立一組 屬性特徵化（attribute characterizations），細化品質屬性的含義
• 將其分解為 子屬性（subattributes）。例如將 development distributability 分解為：軟體分割（software segmentation）、軟體組合（software composition）、團隊協調（team coordination）
• 與利害關係人合作撰寫 具體情境
• 從具體情境集合中歸納出 通用情境：觀察所有刺激、回應、度量等的集合，建立各部分的一般化描述
• 此過程的實際範例可參見 Chapter 22 中的 Utility Tree 建構方法

第二步：建立模型（Model the Quality Attribute）#

建立（或更好的是找到現有的）品質屬性概念模型。所謂「模型」，不需要是什麼複雜的東西——只需要理解品質屬性敏感的 參數集合 以及影響這些參數的 架構特性。例如，可修改性的模型可能告訴我們：可修改性是「需要變更的系統位置數量」和「這些位置之間的相互連接程度」的函數。如果你正在為自己的品質屬性建立模型，具體情境集合將引導你的調查方向。

以效能為例，一個簡單的排隊模型（queuing model）可以辨識出影響延遲的七個參數：

• 到達率（Arrival rate）
• 排隊規則（Queuing discipline）
• 排程演算法（Scheduling algorithm）
• 服務時間（Service time）
• 拓撲結構（Topology）
• 網路頻寬（Network bandwidth）
• 路由演算法（Routing algorithm）

模型的威力在於：在模型範圍內，只有這些參數 能影響延遲。而每個參數都可被各種架構決策所影響——這使得模型對架構師而言極為實用。例如路由演算法可以是固定的或負載平衡的；排程演算法需要被選擇；拓撲結構可透過動態增減伺服器來改變。

如果你正在為自己的品質屬性建立模型，其參數可以從情境的各個部分推導：刺激（及其來源）、回應（及其度量）、製品（及其屬性）、環境（及其特性）。

第三步：組合設計方法（Assemble Design Approaches）#

基於模型產生一組控制機制：

• 列舉模型的參數
• 對每個參數，列舉能影響它的架構特性與機制：
  • 回顧你熟悉的機制，逐一詢問它們如何影響該參數
  • 搜尋成功處理此品質屬性的既有設計
  • 搜尋相關出版物與部落格文章，嘗試歸納其觀察與發現
  • 尋找該領域的專家進行訪談或諮詢

這個方法之所以可行，是因為模型的參數數量有限，且對每個參數而言，影響它的架構決策也是有限的。這使得設計問題變得 可處理（tractable）——從無窮的可能性中收斂為一個有限且合理的機制清單。

延伸閱讀重點#

• Wikipedia 的「List of system quality attributes」列出了超過 80 個 不同的品質屬性定義，可能是最全面的清單
• [Bass 19] 的 Chapter 8 提供了部署管線（deployment pipeline）品質屬性的清單，包括 traceability、testability、tooling 和 cycle time

本章重點回顧#

• 品質屬性遠超過本書專章討論的十個，架構師必須準備好處理 任何 品質屬性需求
• 標準清單（如 ISO 25010）可作為 檢核工具，但不應盲目遵循，也無法替代深入的情境分析
• 品質屬性的 名稱本身沒有意義——只有透過具體情境才能精確表達需求
• 面對新品質屬性的三步驟方法：擷取情境 → 建立模型 → 組合設計方法，提供了一個系統化的應對框架
• 軟體品質屬性與系統品質屬性、開發過程品質屬性相互關聯，架構師需要具備全局視野
• 開發期戰術 傾向分離與封裝責任，效能戰術 則傾向將事物整合在一起——兩者天生處於衝突中。量化這些取捨是架構師持續面對的挑戰