SWE.3 Software Detailed Design and Unit Construction 軟體細部設計與單元開發
ASPICE 標準解讀 — 軟體工程流程
目錄: Automotive SPICE(ASPICE)標準解讀 / 軟體工程流程SWE.1 軟體需求分析
SWE.2 軟體架構設計
SWE.3 軟體細部設計與單元開發
SWE.4 軟體單元驗證
SWE.5 軟體整合與整合測試
SWE.6 軟體合格測試
流程目的(Process Purpose)
The purpose of the Software Detailed Design and unit construction Process is to provide an evaluated detailed design for the software components and to specify and to produce the software units.
軟體細部設計與單元該發流程的目的是為軟體組件提供經過評估的細部設計，用以明確說明和產出軟體單元。
額外說明：標準與筆者的描繪的名詞差異在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.3.BP1: Develop software detailed design.
SWE.3.BP1: 制定軟體細部設計
[Outcome 1]
Develop a detailed design for each software component defined in the software architectural design that specifies all software units with respect to functional and nonfunctional software requirements.
針對定義在軟體架構設計中的每個軟體組件，制定細部設計。在細部設計中，根據功能性與非功能性的軟體需求去明確說明所有的軟體單元。
額外說明:標準中提到，所有的軟體組件都需要開展細部設計。然而，這裡還有存在一個特別的前提。前提是，如果軟體單元需要被實作產出，就需要將軟體組件開展出細部設計。反之，則不需要。舉一個實務的例子，讓讀者明白這項前提。在軟體架構設計時，有一個重要的步驟為「評估可供選擇的軟體架構」，經這個步驟後，在架構圖上可以標示每個架構元件的評估結果。如下圖所示，圖中標示紅框的Module為採購品，而藍框的Module為沿用品；在這種情況下，僅需要針對M1、M6、M7、M9這四個模組開展細部設計即可。其他模組：
* M2、M8這兩個模組則需要評估所沿用的舊專案是否留存細部設計的文件，如果存在，則需要評估可沿用的百分比，沿用可重複使用的部分，針對不可沿用或修改的部分，稍作修改即可；
* 針對M3、M4、M5這三個模組，由於這三個模組為外部採購件，因此不需要再細部展開。值得一提的是，雖然外部採購不需要額外的展開，但是這些採購件也需要符合ASPICE的規範，可以請廠商提出相關證明，或是證明該廠商的能力等。
—
SWE.3.BP2: Define interfaces of software units.
SWE.3.BP2: 定義軟體單元的介面
[Outcome 2]
Identify, specify and document the interfaces of each software unit.
識別、明確說明及紀錄軟體單元間的介面。
額外說明:在SWE.2及SWE.3的介面定義有2個明顯的差異，在SWE.2的定義如下: Identify, develop and document the interfaces of each software element.主要差異：SWE.2針對軟體元件，根據筆者的定義則包含軟體組件及軟體模組。
次要差異：SWE.2講「制定(develop)」介面，而SWE.3則是「明確說明(Specify)」；這兩者的差異是，在SWE.2時，大部分的軟體組件與模組是根據軟體的需求定義繪製，介面是透過組件跟模組之間的關係，開發定義出來；SWE.2所開發定義的介面，必須詳細到讓SWE.3可以使用，而且必須明確說明到讓程式開發工程師足以根據SWE.3的說明來撰寫程式。
—
SWE.3.BP3: Describe dynamic behavior.
SWE.3.BP3: 描述動態行為
[Outcome 3]
Evaluate and document the dynamic behavior of and the interaction between relevant software units.
評估及紀錄相關軟體單元間的動態行為與互動。
NOTE 1: Not all software units have dynamic behavior to be described.
備註1:並非所有的軟體單元都有動態行為。
額外說明:描繪軟體單元的動態行為，一般也會以SWE.2的軟體組件、模組的動態行為作為主要基礎。值得一提的是，在SWE.3不只要評估單元間的動態行為，亦要評估單元間的互動性。
—
SWE.3.BP4: Evaluate software detailed design.
SWE.3.BP4: 評估軟體細部設計
[Outcome 1,2,3,4]
Evaluate the software detailed design in terms of interoperability, interaction, criticality, technical complexity, risks and testability.
從互操作性、互動性、關鍵性、技術複雜度、風險和可測試性等方面評估軟體細部設計。
NOTE 2: The results of the evaluation can be used as input for software unit verification.
備註2:評估的結果可以被作為軟體單元驗證的輸入。
額外說明: SWE.3 BP4 提到的評估範圍非常的廣，而且這些評估是寫在BP的主文裡面，這表示這些評估都是必要評估的項目。根據需要評估的項目，相關解釋跟說明如下：互操作性(Interoperability)互操作性原本的意思是不同系統、設備、應用程式或產品以協調方式進行連接和通信的能力，而無需最終用戶的努力。互操作組件的功能包括資料訪問，資料傳輸和跨平台(組織)協作，無論其開發者或來源如何。一個互操作性佳的系統也可以被常被說成高度的兼容性。互操作性可幫助架構實現更高的效率和更全面的資訊訊息圖。在這邊，可以解釋成「跨模組」或「跨組件」的連接和通信能力。請參考下圖。圖中，M1U1、M1U2、M1U3為模組1(M1)內部單元間的互動關係(亦可解釋為互動性)，從圖中可以看出M1U3提供兩種不同的介面讓M1U1和M1U2呼叫；M5U1、M7U2、M1U3為跨模組(模組1、模組5和模組7)單元間的互動關係(這邊可以解釋為互操作性)。在單元開發的實務上，不同模組，甚至是不同組件，可能會交由不同人或是不同的單位來撰寫；因此當一個單元存在跨模組，或是跨組件的互動關係時，特別會需要交代互操作性的來源、目的、資料交換格式及協議；當然這些資訊，可以協助軟體單元驗證流程，有更好且更多的資訊來檢視跟驗證。更複雜的情況？圖中，假設M5、M7都是外部採購品，而且分別隸屬於不同的供應商；經過分析，發現M1U3與M5U1、M7U2存在互操作性時，而M5U1跟M7U2所存在的資料格式跟交換協議都有很大的分歧時，這個時候該如何是好？是要砸重本，把這個複雜的處理都寫在M1U3中嗎？所謂評估軟體細部設計，意思便是當發現這種複雜情況出現時，應考慮重構現行的架構，以免增添開發與維護的困擾。
—
SWE.3.BP5: Establish bidirectional traceability.
SWE.3.BP5: 建立雙向追溯
[Outcome 4]
Establish bidirectional traceability between software requirements and software units. Establish bidirectional traceability between the software architectural design and the software detailed design. Establish bidirectional traceability between the software detailed design and software units.
建立軟體需求與軟體單元的雙向追溯。建立軟體架構設計與軟體細部設計的雙向追溯。建立軟體細部設計與軟體單元的雙向追溯。
NOTE 3: Redundancy should be avoided by establishing a combination of these approaches that covers the project and the organizational needs.
NOTE 4: Bidirectional traceability supports coverage, consistency and impact analysis.備註3: 建立涵蓋專案和組織需求的一套追溯管理方法，該方法應該盡量避免多餘的追溯。
備註4: 雙向追溯支援覆蓋性、一致性和影響分析。
—
SWE.3.BP6: Ensure consistency.
SWE.3.BP6: 確保一致性
[Outcome 4]
Ensure consistency between software requirements and software units. Ensure consistency between the software architectural design, the software detailed design and software units.
確保軟體需求與軟體單元的一致性。確保系統架構設計、系統細部設計與軟體單元的一致性。
NOTE 5: Consistency is supported by bidirectional traceability and can be demonstrated by review records.
備註5: 可以透過BP5所建立的雙向追溯來確保一致性；審查記錄可以用來作為一致性的證明。
—
SWE.3.BP7: Communicate agreed software detailed design.
SWE.3.BP7: 溝通商定的軟體細部設計
[Outcome 5]
Communicate the agreed software detailed design and updates to the software detailed design to all relevant parties.
溝通商定的軟體細部設計及其更新給所有相關的成員。
—
SWE.3.BP8: Develop software units.
SWE.3.BP8: 開發軟體單元
[Outcome 6]
Develop and document the executable representations of each software unit according to the software detailed design.
根據軟體細部設計，開發並記錄每個軟體單元的可執行表示。
工作產出(Output Work product)
04-05 軟體細部設計 [Outcome 1,2,3]11-05 軟體單元 [Outcome 6]13-04 溝通紀錄 [Outcome 5]13-19 審查記錄 [Outcome 4]13-22 追溯記錄 [Outcome 4]
感謝閱讀本文章！
如果你對文章內容有任何問題，請隨時與我聯絡。
if you found any question in the article, please feel free to contact me.
mailto: linchewing@gmail.com
