SWE.2 Software Architectural Design 軟體架構設計

ASPICE 標準解讀 — 軟體工程流程

Published in

ASPICE標準解讀

3 min readFeb 17, 2020

目錄: Automotive SPICE(ASPICE)標準解讀 / 軟體工程流程SWE.1 軟體需求分析
SWE.2 軟體架構設計
SWE.3 軟體細部設計與單元開發
SWE.4 軟體單元驗證
SWE.5 軟體整合與整合測試
SWE.6 軟體合格測試

流程目的(Process Purpose)

The purpose of the Software Architectural Design Process is to establish an architectural design and to identify which software requirements are to be allocated to which elements of the software, and to evaluate the software architectural design against defined criteria.

軟體架構設計流程的目的分別是：其一是完成軟體架構設計的建立；其二是識別軟體需求對應的軟體架構設計元件；其三是跟據已定義的標準來進行軟體架構設計的評估。

額外說明：標準與筆者的描繪的名詞差異在ASPICE 3.1的標準中提到幾個名詞，可能會與筆者描述的名詞有所差異。在開始本流程的閱讀前，請參考「ASPICE 關鍵觀念3: 元件、組件、單元、項目」文章中的"元件、組件、單元間的關係"。

流程結果(Process Outcome)

成功實作軟體架構設計流程，其相應的結果如下：
1) [Outcome 1]一個軟體架構設計被定義，其軟體元件被識別。
2) [Outcome 2]軟體需求被分配到軟體元件
3) [Outcome 3]軟體元件的介面被定義
4) [Outcome 4]軟體元件的動態行為及資源消耗目的被定義
5) [Outcome 5]軟體需求與軟體架構設計的一致性與雙向可追溯性被建立;
6) [Outcome 6]軟體架構設計已商定，並向所有受影響的成員溝通

基礎實踐(Base Practices)

SWE.2.BP1: Develop software architectural design.
SWE.2.BP1: 制定軟體架構設計
[Outcome 1]

Develop and document the software architectural design that specifies the elements of the software with respect to functional and non-functional software requirements.

制定及紀錄軟體架構設計。軟體架構設計中，根據功能性與非功能性的軟體需求去明確說明軟體元件。

NOTE 1: The software is decomposed into elements across appropriate hierarchical levels down to the software components (the lowest level elements of the software architectural design) that are described in the detailed design.
備註1:將軟體分解為適當層級結構的各個元件，直到軟體組件。(軟體組件是軟體架構設計中最小層級的元件)；軟體組件將在軟體細部設計(SWE.3)中描述。

SWE.2的拆解從System Elements往下拆解；在SYS.3，System Elements通常是Software, Hardware或Mechanical，在這裡僅針對Software進行細部拆解。

額外說明：上圖為架構設計的層級結構，從系統的為首，細到最小的軟體單元；如圖中所示，SYS.3主要從整個產品的角度來拆解，從System開始，向下最小拆解到系統元件(System Elements)，這邊所謂的System Elements指的是硬體、軟體或機構。進入SWE.2，將會承接SYS.3的最小單位，也就是系統元件，開始往下拆解；由於SWE.2是軟體架構設計，因此僅會針對軟體的系統元件進行拆解；以上圖為例，SWE.2將軟體拆分成組件(Components)，最細將拆解到模組(Modules)，而模組到單元(Unit)將會軟體細部設計中描述。值得一提的是，拆的層級越多，其整合的次序也就會越多。許多歐洲的客戶廠商，通常不會接受Big Bang的整合模式，因此當架構的層級定義的越多越細，到時候在SWE.5進行整合的時候，就需要考量細一些。特別說明：過去台灣的廠商多半沒有系統層級的概念，本範例的層級結構僅作為一個比較簡易的範例，詳細的拆解方式可由專案團隊進行定義。業界一般常見的層級結構，也包括Layer、Group、sub-modules等...，在業界並沒有標準的分解層級定義；另外，常見的AUTOSAR亦有定義標準的軟體結構，這個部分將會另外寫一篇文章，跟大家說明AUTOSAR跟軟體架構設計的分層定義。

—

SWE.2.BP2: Allocate software requirements.
SWE.2.BP2: 分配軟體需求
[Outcome 2]

Allocate the software requirements to the elements of the software architectural design.

將軟體需求分配到軟體架構設計中的軟體元件。

額外說明:這邊所提到的軟體元件(Elements of the software architectural design)，必須要根據BP.1實際拆解的結構而定。這邊也可以透過Traceability來體現分配的結果。本BP所提到的軟體元件，不只是組件(Components)，也包含組件間的介面。

—

SWE.2.BP3: Define interfaces of software elements.
SWE.2.BP3: 定義軟體元件的介面
[Outcome 3]

Identify, develop and document the interfaces of each software element.

識別、制定及紀錄軟體元件間的介面。

額外說明：軟體介面一般來說會分成內部介面與外部介面；其中，外部介面可以參考系統架構設計。根據BP1所定義的層級結構，介面亦需根據層級結構定義。首先，以組件開始，定義組件間的介面；接續著，將組件拆分成模組，再定義模組間的介面。常見的問題是，這邊的介面要定義到多仔細？因為軟體的細部設計需要參考架構設計的資訊，因此建議這邊所定義的資訊要足夠讓細部設計的設計師得以進行細部的設計。

—

SWE.2.BP4: Describe dynamic behavior.
SWE.2.BP4: 描述動態行為
[Outcome 4]

Evaluate and document the timing and dynamic interaction of software elements to meet the required dynamic behavior of the system.

評估及紀錄軟體元件之間的時序和動態互動，以滿足系統所需的動態行為。

NOTE 2: Dynamic behavior is determined by operating modes (e.g. start-up, shutdown, normal mode, calibration, diagnosis, etc.), processes and process intercommunication, tasks, threads, time slices, interrupts, etc.
NOTE 3: During evaluation of the dynamic behavior the target platform and potential loads on the target should be considered.
備註2:動態行為取決於運作模式 (例如：開機、關機、正常模式、教準、診斷，等…)、軟體程序和程序內部通訊、任務、執行緒、時間片段、中斷等。
備註3:在評估動態行為時，應考慮目標平台和目標上的潛在負載。

—

SWE.2.BP5: Define resource consumption objectives.
SWE.2.BP5: 定義資源消耗目標
[Outcome 4]

Determine and document the resource consumption objectives for all relevant elements of the software architectural design on the appropriate hierarchical level.

決定並紀錄所有相關軟體架構元件的資源消耗目標；需要考量到相對應的層級結構下的軟體架構元件。

NOTE 4: Resource consumption is typically determined for resources like Memory (ROM, RAM, external / internal EEPROM or Data Flash), CPU load, etc.
備註4:一般需要被決定的資源(資源消耗)，可以是記憶體(ROM, RAM, 內外部 EEPROM 或 Data Flash)、CPU負載，等。

—

SWE.2.BP6: Evaluate alternative software architectures.
SWE.2.BP6: 評估可供選擇的軟體架構
[Outcome 1,2,3,4,5]

Define evaluation criteria for the architecture. Evaluate alternative software architectures according to the defined criteria. Record the rationale for the chosen software architecture.

針對軟體架構定義評估準則。根據所定義的評估準則，評估可供選擇的軟體架構，並紀錄最後選定軟體架構的理由。

NOTE 5: Evaluation criteria may include quality characteristics (modularity, maintainability, expandability, scalability, reliability, security realization and usability) and results of make-buy-reuse analysis.
備註5: 評估準則可包含品質屬性(模組化、可維護性、延展性、擴充性、可靠性、安全實現性、可用性)及「自制-購買-重用」的分析結果

—

SWE.2.BP7: Establish bidirectional traceability.
SWE.2.BP7: 建立雙向追溯
[Outcome 5]

Establish bidirectional traceability between software requirements and elements of the software architectural design.

建立軟體需求與軟體架構設計的雙向追溯。

NOTE 6: Bidirectional traceability covers allocation of software requirements to the elements of the software architectural design.
NOTE 7: Bidirectional traceability supports coverage, consistency and impact analysis.
備註6: 雙向追溯包含軟體需求分配到軟體架構設計中的軟體元件。
備註7: 雙向追溯援覆蓋性、一致性和影響分析。

額外說明：在軟體架構設計中，通常架構會因為層級結構再拆成不同的架構，以上圖為例，軟體架構分成組件(Components)和模組(Modules)兩個層級。當建立雙向追溯時，需要先建立軟體需求到組件的雙向追溯，亦需要建立組件到模組的雙向追溯。上圖中，雙向追溯定義如下：
綠色: 系統需求←→系統架構 (定義在SYS.3中)
橘子: 系統需求←→軟體需求、系統架構←→軟體需求 (定義在SWE.1中)
紅色: 軟體需求←→軟體架構(先組件、後模組，共有兩層) (定義在SWE.2中)接續同一個案例，在SWE.3進行細部設計時，則需要建立模組到單元(Unit)的雙向追溯。

—

SWE.2.BP8: Ensure consistency.
SWE.2.BP8: 確保一致性
[Outcome 1,2,5,6]

Ensure consistency between software requirements and the software architectural design.

確保軟體需求與軟體架構設計的一致性。

NOTE 8: Consistency is supported by bidirectional traceability and can be demonstrated by review records.
備註8: 可以透過利益相關者需求與系統需求的雙向追溯來比對文件之間的一致性；可以透過審查記錄來展示一致性的確保。

—

SWE.2.BP9: Communicate agreed software architectural design.
SWE.2.BP9: 溝通商定的軟體架構設計
[Outcome 6]

Communicate the agreed software architectural design and updates to software architectural design to all relevant parties.

溝通商定的軟體架構設計及其更新給所有相關的成員。

工作產出(Output Work product)

04-04 軟體架構設計 [Outcome 1,2,3,4,5] 13–04 溝通記錄 [Outcome 6] 13-19 審查記錄 [Outcome 5] 13-22 追溯記錄 [Outcome 5] 17-08 介面需求規格書 [Outcome 3]

* ASPICE網站
* ASPICE 3.1標準

感謝閱讀本文章！

如果你對文章內容有任何問題，請隨時與我聯絡。
if you found any question in the article, please feel free to contact me.

mailto: linchewing@gmail.com