本流程為ASPICE v4.0標準中的軟體工程流程 — SWE.2 Software Architectural Design 軟體架構設計；本文章為「ASPICE v4.0 標準解讀」系列文章，筆者將針對ASPICE標準條文提供解讀與說明，期許本篇文章能夠為讀者，解決標準導入時的疑惑。
流程目的(Process Purpose)
The purpose is to establish an analyzed software architecture, comprising static and dynamic aspects, consistent with the software requirements.
本流程的目的是建立一個與軟體需求相符的已分析軟體架構，包括靜態和動態等觀點。
流程結果(Process Outcome)
成功實作本流程，其相應的結果如下：[Outcome 1] 設計了一個涵蓋靜態及動態觀點的軟體架構。[Outcome 2] 根據已定義的標準，分析軟體架構。[Outcome 3] 在軟體架構和軟體需求之間建立一致性和雙向追溯。[Outcome 4] 與所有相關方溝通已同意的軟體架構。
基礎實踐(Base Practices)
SWE.2.BP1: Specify static aspects of the software architecture
SWE.2.BP1: 具體描述軟體架構的靜態觀點
Specify and document the static aspects of the software architecture with respect to the functional and non-functional software requirements, including external interfaces and a defined set of software components with their interfaces and relationships.
根據功能和非功能性系統需求，具體說明並記錄系統架構的靜態觀點，包括外部介面以及一系列已定義系統元件及其介面和關係。
Note 1: The hardware-software-interface (HSI) definition puts in context the hardware design and therefore is an aspect of system design (SYS.3).
備註1: 硬體軟體介面（HSI）的定義說明了硬體設計的背景，這是系統設計的一部分。
額外說明 -- HSI (Hardware Software Interface) 對於軟體架構的關係 HSI首次在系統架構設計時被定義。這份介面規格書簡單地劃定了軟體與硬體之間的交互介面。在系統架構階段，由於軟硬體之間的互動尚未詳細明確，這份文件通常會在SWE.1軟體需求分析階段進行進一步的細化。 談到軟體架構設計，這個過程需要描述兩種類型的介面。第一種是軟體組件內部的介面，其詳細規格可以從軟體組件的動態圖中總結出來。第二種則是軟體組件對外的介面，包括提供給外部軟體的API以及軟體對硬體的存取介面。 在此，HSI文件對於設計軟體組件對外的介面特別有用。更確切地說，HSI文件為軟體組件存取硬體提供了重要的參考資料。在設計階段，如果HSI文件不夠完整，軟體架構設計人員可以依據軟體組件所需滿足的功能，進一步細化HSI文件，從而更清楚地定義軟硬體之間的交互規格。 舉例來說，假設一款軟體需要與硬體裝置進行通訊，初步在系統架構階段產出的HSI文件，可能只定義了基本的資料傳輸方式。隨著需求的深入分析，軟體設計師可能會發現需要更多的控制命令或更細致的資料管理，這時他們就會更新HSI文件，加入更多的技術細節，例如特定的協議或增強的安全特性。這樣的進一步發展有助於確保軟體與硬體的高效且安全的互動。
—
SWE.2.BP2: Specify dynamic aspects of the software architecture.
SWE.2.BP2: 具體描述軟體架構的動態觀點
Specify and document the dynamic aspects of the software architecture with respect to the functional and non-functional software requirements, including the behavior of the software components and their interaction in different software modes, and concurrency aspects.
根據功能和非功能性軟體需求，具體說明並記錄軟體架構的動態觀點，包含在不同軟體模式及同步觀點下，軟體元件間的行為與互動。
Note 2: Examples for concurrency aspects are application-relevant interrupt handling, preemptive processing, multi-threading.
Note 3: Examples for behavioral descriptions are natural language or semi-formal notation (e.g, SysML, UML).
備註2: 同步方面的例子有”應用相關的中斷處理”、”可搶佔的排程”和”多執行緒”。
備註3: 行為描述可以用自然語言或半正式的表示法，如SysML或UML。
額外說明 -- Preemptive Processing 可搶佔(插隊)排程 為了讓軟體能夠同時處理多個任務，電腦系統引入了「排程」的概念。所謂排程，就是一種技術，它允許中央處理器（CPU）高效地處理各個程序。在這裡，程序的最小運作單位可能是執行緒（Thread）或是完整的程序（Process）。 其中，可搶佔排程（Preemptive Processing）是排程技術的一種形式，它允許一個程序在運行中被另一個更需要立即處理的程序中斷。這種方式與非搶佔排程（Non-preemptive Processing），即程序一旦開始執行便不會被中斷，恰巧相反。由於可搶佔排程是動態進行，一般來說可以提供更好的效能。然而，這種方法可能會在程序執行途中被中斷，從而引發程序間的同步問題。 因此，在設計軟體架構時，開發者選擇使用「可搶佔排程」，必須考慮這些同步問題。解決這些問題通常需要依靠硬體支持的資料儲存或進行全域變數的存取控制，以確保程序間的正確互動和資料一致性。
額外說明 -- 自然語言、半正式表示法 用自然語言來描述動態行為，可以簡單的理解成，用PPT來繪製時序圖、資訊傳達圖、等。 用半正式表示法，則需要遵守SysML和UML的描述格式。
—
SWE.2.BP3: Analyze software architecture.
SWE.2.BP3: 分析軟體架構
Analyze the software architecture regarding relevant technical design aspects and to support project management regarding project estimates. Document a rationale for the software architectural design decision.
對軟體架構進行技術設計方面的分析，分析結果可用以支援專案管理的專案預估。記錄軟體架構設計決策的理由。
Note 4: See MAN.3.BP3 for project feasibility and MAN.3.BP5 for project estimates.
Note 5: The analysis may include the suitability of pre-existing software components for the current application.
Note 6: Examples of methods suitable for analyzing technical aspects are prototypes, simulations, qualitative analyses.
Note 7: Examples of technical aspects are functionality, timings, and resource consumption (e.g, ROM, RAM, external / internal EEPROM or Data Flash or CPU load).
Note 8: Design rationales can include arguments such as proven-in-use, reuse of a software framework or software product line, a make-or-buy decision, or found in an evolutionary way (e.g, set-based design).
備註4: 有關專案可行性，請參見MAN.3.BP3；有關專案估算，請參見MAN.3.BP5。
備註5: 分析可能包括”現有軟體組件”對當前應用的適用性。
備註6: 分析技術方面適用的方法包括原型、模擬、質性分析。
備註7: 有關技術方面，包括功能性、時間緒和資源消耗（例如: ROM、RAM、外部/內部 EEPROM 或快閃資料或 CPU 負載）。
備註8: 關於「軟體架構的採用理由」， 可包含已證實的使用、重用軟體框架或軟體產品線、自主開發-採購評估(make-buy)、或其他創新的方法(例如:基於集合的設計)
額外說明 -- 「Set-based design」基於集合的設計 請參考ASPICE SYS.3 BP3文章中的說明
—
SWE.2.BP4: Ensure consistency and establish bidirectional traceability
SWE.2.BP4: 確保一致性並建立雙向追溯
Ensure consistency and establish bidirectional traceability between the software architecture and the software requirements.
建立軟體架構與軟體需求之間的雙向追溯，並確保之間的一致性。
Note 9: There may be non-functional software requirements that the software architectural design does not trace to. Examples are development process requirements. Such requirements are still subject to verification.
Note 10: Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage. Traceability alone, e.g, the existence of links, does not necessarily mean that the information is consistent with each other.
備註9: 軟體架構設計有可能無法追溯到一些非功能性軟體需求。如開發流程的要求，但這些需求仍需被驗證。
備註10: 雙向追蹤性進一步支持一致性，有助於變更請求的影響分析，以及驗證覆蓋範圍的展示。僅僅存在追蹤性（例如: 資料之間存在鏈接），並不必然意味著資訊彼此一致。
—
SWE.2.BP5: Communicate agreed software architecture.
SWE.2.BP5: 溝通已同意的軟體架構
Communicate the agreed software architecture to all affected parties.
將已獲得共識的軟體架構，向所有相關人員進行溝通。
額外說明 -- 已獲得共識 請參考ASPICE SYS.3 BP5 文章中的說明
額外說明 -- 關於溝通對象 如果只有取得CL1，則建議溝通對象是下一個流程，這裡包含SWE.3 及 SWE.5。 如果要取得CL2，則建議溝通對象是除了下一個流程之外的其他管理及支援流程。
輸出資訊項目 (Output Information Item)
04–04 軟體架構13–51 一致性證據13–52 溝通證據15–51 分析結果
