SWE是Software engineering process group的縮寫，也就是說它本質上是個功能組。SWE下轄6個過程。在過程評估模型中，過程實施指標包含兩個，一個是BP，一個是WP。
BP（Basic Practice）面向活動，講的是你需要做的事，即這個活動在開發過程中有沒有做這幾件必要的事？比如你說你去打掃廁所，那你需要擦馬桶、擦水龍頭、擦花灑、拖地面......總之是個事兒。這個在Automotive SPICE官方文檔中對應的是綠區，講的是How。
WP（Work Product）面向結果，即最終呈現給評審員的材料。你說你把廁所打掃干凈了，那你自己記錄的Checklist呢？照片呢？總之是可被審查的成果。這個在Automotive SPICE官方文檔中屬于藍區的范疇，講的是What。
我們今兒這篇文章只討論BP，因為BP的活如果都干了，大多數的WP你手里也就有了。SWE中包含多少個BP呢？一共是4+(5+6+5+3+4+3)+3*6=48個BP。這個計算式子是怎么來的呢？
之前@東曉一家介紹過PDCA管理法（見先決知識點），定策略肯定屬于Plan的范疇，建立雙向可追溯性和確保一致性則屬于Check，溝通與總結測試結果屬于Act/Adjust的范疇。剩下的這些BP比如畫架構、定接口、寫測試用例肯定就算是Do的范疇了。
對于Check和Adjust，我們需要做三件事，即建立雙向可追溯性、確保一致性、溝通和總結測試結果。我們發現SWE中的六個過程（Process），每個過程都有這三件事需要做。算下來一共是3*6=18個BP。
對于Plan，我們需要做策略，SWE中有4個策略需要制訂，即軟件單元驗證策略、軟件集成策略、軟件集成測試策略和軟件合格性測試策略。
剩下的26個BP就都是Do了。我們可以采用東曉一家的三字法。這里我有小部分用的不是東曉老師的說法，關于用詞每個人都有自己的喜好吧。
現在我們知道了，以前不畫架構，不寫每個函數具體的流程圖，不寫開機序列的順序圖，一心想寫好代碼，直接發給黑盒測試組測試的流程是不正規的，是不符合功能安全的。那遵循軟件開發的6個過程，48個基本實踐，怎么這么繁瑣？第一次執行時有沒有重點可尋？是否滿足二八原則呢？即能否只把20%的BP做好就能達到80%的效果呢？庫樂瑪公司（KUGLER MAAG CIE）提供了的Automotive SPICE的免費視頻教程，我們看看能否快速地理解Automotive SPICE軟件開發6大過程的核心要點。
后臺回復：“ECU008獲取ASPICE3.1中文版標準！
這個過程可幫助您的組織將系統需求中與軟件相關的部分轉化為一組軟件需求。
為什么我們要用文檔來記錄軟件需求？
通常來說，您已經有了系統需求或客戶需求，那為什么還要投入時間和精力來記錄其他軟件需求呢？在一個項目中，你希望按時、在預算內、以客戶要求的質量交付商定過的結果。如果不記錄軟件需求，可能會忽略掉功能或完全誤解客戶的期望。這會導致額外的工作、成本和延遲。您還可以忽略對軟件的功能或非功能方面至關重要的軟件方面。這可能導致錯誤的開始，甚至是額外的開發周期。
這一過程與SYS的上下游都有緊密的聯系，上游即系統需求分析（SYS.2），系統架構設計（SYS.3），下游即軟件架構設計（SWE.2）和軟件合格性測試（SWE.6）。其他依賴性強的流程是項目管理（MAN.3）和配置管理（SUP.8），例如，因為發布管理和缺陷管理（SUP.9）和變更請求管理（SUP.10）。這里的聯系是，測試中發現的缺陷必須得到解決，錯誤修復和更改請求必須在回歸測試中得到解決。
以下是Automotive SPICE?軟件需求分析中最重要的三個關鍵點。
1-1 你需要考慮的不僅僅是客戶的要求
文本化記錄軟件需求的一個重要原因是，你需要考慮的不僅僅是客戶的期望。軟件必須符合標準、規范和其他增加需求數量的規定。出于文檔目的，將系統需求或僅在軟件開發的情況下、客戶和其他利益相關者的需求映射到反映軟件內部視圖的軟件需求中。軟件需求反過來構成了軟件合格性測試（SWE.6）和所有下游流程的基礎，例如軟件架構設計（SWE.2）。
1-2 確保你分析并理解需求的含義
顧名思義，這個過程的另一個面是需求分析。您應分析需求的可行性或風險。這兩者緊密相連。如果您不確定某個需求的可行性，則存在固有的風險，因為可能需要時間才能找到解決方案，或者根本沒有解決方案。顯然，這與我們在項目管理（MAN.3）中必須執行的評估有著密切的聯系，尤其是MAN.3 BP5。另一個需要分析的主題是可測試性(testability)。當然，測試人員的支持可以用來確保這一點。通常，測試人員還被要求評審(review)需求。此外，分析應涵蓋技術影響。這包括評估需求之間的依賴關系。
我在關于系統需求分析（SYS.2）的視頻中加入了一個例子。
最后，分析還應涵蓋需求的業務方面。因此，應確定各種要求的實施如何影響成本和時間。現在，你可以說你不能在需求數據庫中記錄所有這些。請記住，Automotive SPICE?沒有說明您應在何處文本記錄這些信息。
例如，您可以在需求數據庫中介紹分析的第一部分（可行性和風險）、相應和相關變更請求中的技術含義，以及項目管理工具中對成本和進度的影響。
1-3 建立可追溯性和一致性
該過程還要求您確保軟件需求、系統需求和系統架構之間的可追溯性。
然而，Automotive SPICE?明確表示不需要冗余。您可以決定是希望跟蹤系統需求、系統架構還是兩者的組合。這取決于哪種方法以最佳方式支持您的開發，而不是哪種方法對您更容易。
可追溯性可通過DOORS等超鏈接、Rectify等特定的可追溯性工具、可追溯性矩陣或你們公司工具環境支持的其他可管理方式來建立。
可追溯性的目的是支持以下3項：
——一致性檢查，即驗證軟件需求的完整性和準確性。
——變更請求或缺陷情況下的影響評估。
——報告的執行情況。
這個點的另一部分是確保一致性。
一致性意味著您可以根據系統需求和系統架構分別證明軟件需求的完整性和正確性。
這只能通過評審（review）來確定。
如果您跳過此評審，您可能有不完整或錯誤的軟件需求。最糟糕的是，您甚至可能沒有注意到軟件合格性測試（SWE.6）中的缺陷，因為該測試是根據您的軟件需求執行的。如果這些都是錯誤的，你的測試可能不會顯示任何錯誤的行為。所以，請不要跳過評審這個環節！
這個過程有助于組織搭建和記錄軟件產品的內部邏輯。
軟件架構的目標是什么？期望是既然您已經有了軟件需求（SWE.1），這些需求描述了軟件應該做什么。軟件架構設計的目的是定義如何實現軟件需求中記錄的功能。簡而言之，需求描述了“什么what”，架構則描述了“如何how”。
許多組織和項目在理解如何記錄體系結構以及需要哪些元素方面存在問題。
軟件架構的三個關鍵點
——恰當的視圖
——接口
——可追溯性
2-1 架構視圖
通常，軟件架構只包括軟件的物理視圖、框圖等。在如今大多數復雜的項目中，這顯然是不夠的。當然，您希望對軟件進行分層分解，以演示和解釋如何在不同組件和子組件中實現功能性和非功能性需求。
其他的視圖包括：
——動態視圖，
——顯示特定功能分解的特定功能視圖，
——狀態流程圖，
——接口等等。
通常，系統越復雜，需要的視圖就越多。
由于不同的視圖必須保持一致，因此應該使用適當的UML或SysML工具。該工具需要支持一致性檢查。
2-2 接口
評估中經常遇到的一個陷阱就是缺乏對接口的詳細描述。
評審員希望看到的接口文檔的內容包括：
——名稱
——類型
——單位
——Resolution
——范圍
——默認值
等等。
如果沒有這些信息，就不可能在集成測試中對接口進行適當的測試。同樣，在適當的UML或SysML工具中描述這些接口才能夠支持不同視圖之間的一致性。
作為對SYS.2中定義的補充，當前章節從進程間通信機制和總線通信機制的角度考慮了軟件組件之間的特定軟件接口。
2-3 可追溯性
這個過程還要求您確保軟件架構和軟件需求之間的可追溯性。
通常情況下，需求和架構之間存在工具造成的不連續，這會使證明可追溯性變得困難。
可追溯性的目的是：
——支持一致性檢查，即檢查軟件需求覆蓋范圍的完整性和準確性。
——支持變更請求或有缺陷情況下的影響評估。
——支持利益相關者的期望報告，并確定需求是否已在架構中實現。
Automotive SPICE中的軟件詳細設計和單元構造過程（也稱為SWE.3）幫助您的組織為軟件組件（SWC）提供經過評估的詳細設計，并指定和生產軟件單元。
軟件詳細設計的目標是什么？許多組織和項目在理解如何記錄詳細設計方面存在問題。那么，在這個過程中你應該管理的三個方面是什么呢？
以下是Automotive SPICE?中軟件詳細設計的最重要方面。
3-1 細節的層次
通常，組織很難確定詳細設計應該有多么具體。一個很好的辦法是記住詳細設計的目的是什么。它是實現代碼和單元測試的基礎。尤其是單元驗證需要詳細描述。在這方面，必須要考慮覆蓋范圍。
在安全方面，ISO26262中的關鍵軟件可提供指導。在非安全軟件中，通常至少需要C0-或聲明（statement）覆蓋，一些客戶要求C1-或分支覆蓋。覆蓋率目標越高，詳細設計所需的細節就越多。如果您有ASIL-B的分類模塊，則需要C1覆蓋。這意味著您的詳細設計應該識別軟件的不同分支。
3-2 接口
我在評估中經常遇到的一個陷阱是缺乏對外部和內部接口的詳細描述。
接口文檔的預期內容包括：
1.名字
2.類型
3.單位
4.resolutions
5.取值范圍
6.默認值
如果沒有這些信息，就不可能在單元測試中對接口進行適當的測試。
如果外部接口是在架構級別中描述的（SWE.2），并在軟件集成測試（SWE.5）中進行測試，那這當然是可以的。
3-3 文檔的時間安排
在實現代碼之前描述詳細設計。通常情況下，詳細設計是在事后描述的，也就是在編寫代碼之后。
為什么這樣做是一個問題？單元測試應該檢查代碼是否滿足詳細設計。如果在寫代碼之后再寫詳細設計，那么單元測試的關鍵點就丟失了。
現在，你可以說你可能不需要單元測試。關鍵是，您應該從軟件架構而不是代碼中派生出軟件詳細設計。如果這個鏈條斷了，那么文檔的內容和所有的測試就會突然變得毫無意義。因此，在開始編寫代碼之前，必須先編寫軟件詳細設計。
循序漸進地迭代開發軟件詳細設計和代碼并沒有什么錯。
Automotive SPICE?中軟件單元級別的驗證過程（簡稱SWE.4）有助于貴公司證明所實施的軟件單元不僅有效，而且滿足要求。這些是之前在SWE.3中規定的。
Automotive SPICE?中的軟件單元驗證過程可幫助貴公司驗證軟件單元是否以所需的質量實施了詳細設計以及相關的功能性和非功能性需求。最終，這一過程為您作為供應商提供了保證。
單元驗證，這是一系列后續測試中的第一組測試。
如果不進行單元驗證，將產生兩個負面后果：
——并不是所有的問題都能保證在之后被發現，因為后續的測試有不同的重點，比如集成測試和需求測試。
——然而，如果您在更高的測試級別上發現這樣的問題，您將不得不重新運行夾在兩個測試之間的大多數測試。
這是因為單元級別的錯誤行為可能會掩蓋更高測試級別的問題。正如你所見，這個過程可以幫助你發現更多的問題，同時減少你的努力和成本。
以下活動是Automotive SPICE?軟件單元驗證中最重要的三項活動。
4-1 定義軟件單元驗證的策略
正如你可能從我們的一些視頻中了解到的，策略是一種易于理解的教學描述。這對于更大的分布式項目尤其重要，這樣所有人都會知道如何做。
該策略的主要目的是描述您打算如何證明軟件單元符合詳細設計。
需要三種類型的驗證，您應該解釋它們應該如何工作：
——靜態和動態分析，
也就是說，使用分析工具檢查代碼。
——代碼審查，
同事閱讀并審閱同事提供的代碼。
——單元測試，
使用書面測試規范證明符合詳細設計。
此外，Automotive SPICE?需要回歸測試策略。回歸測試僅僅意味著，如果你改變了一個單元中的某些東西，你就可以確保所有沒有改變的東西仍然運行良好。
一個實際的例子：如果使用持續集成（CI），通常會在夜間測試期間再次運行所有單元測試。所以，策略就是我剛才說的這些。
4-2 提供詳細設計的雙向可追溯性和一致性
這里需要三種類型的可追溯性，即用于：
——詳細設計中的每個單元您都知道對應到哪個測試規范。如果每個測試規范都能對應到某個單元，那么可追溯性是雙向的。
——每個單元你都知道代碼審查和靜態分析的結果。
——每個單元測試規范你都知道單元測試結果。
那么一致性意味著什么？例如，對于詳細設計中的單元與相應測試規范之間的關系，一致性要求：
——該單元鏈接到了正確的測試（而不是另一個單元的測試）
——本測試適用于對這個單元進行完整的測試。
如果情況并非如此，則必須鏈接其他測試。
一致性還要求測試能夠真實的正確的測試軟件單元。換句話說：沒有差錯的測試。
4-3 總結和交流測試結果。
這通常被稱為測試總結報告。這份總結報告應該發送給需要這些信息的人，比如開發團隊、項目經理、質量工程師等等。
讓我們仔細看看這份報告應該長成什么樣子：顧名思義，它應該總結結果，隱藏不必要的細節。摘要報告應該傳達的主要信息是什么？它應符合軟件詳細設計。
我將給你一個我在評估中經常看到的反例：報告包含餅圖，顯示了1520項本應執行的測試，但其中112項無法執行，89項測試失敗。就這樣。目前還沒有關于112項測試無法進行的原因和風險的信息。也沒有關于89次失敗測試的問題會產生多大問題的信息。報告也沒有顯示是否與詳細設計相符。事實上，詳細設計一丁點也沒有提到。他們必須將餅圖與956個軟件單元相關聯，而不僅僅是與1520個測試相關聯。我想你已經明白了這一點。當然，這會是評估中的減分項。
Automotive SPICE?中的軟件集成和集成測試過程（也稱為SWE.5）幫助您的組織確保軟件體系結構的各個元素被集成，然后進行測試，以證明它們按照計劃一起工作，并按照軟件架構中的描述進行交互。
在我的課堂和評估中，我遇到了很多問題，比如“嘿，我們做了大量的需求測試，為集成測試付出的額外努力真的值得嗎？”
那么，你的看法是什么？想過嗎？
為了回答這個問題，我們必須首先闡明集成測試的含義。
集成測試的目的是檢查代碼是否符合軟件架構設計。這包括根據SWE.2檢查接口、動態行為和資源消耗。
那么，讓我們把最初的問題修改為：“需求測試能證明符合軟件架構嗎”？答案是：當然不能，因為這些測試針對的是需求，而不是架構。到目前為止，一切順利。但你們中的一些人可能會說：“好吧，明白了。但是，針對軟件架構進行測試的附加值是什么？如果代碼功能運行良好，這還不夠好嗎？”
讓我們仔細看看：在需求測試中是否可以檢測到代碼與軟件架構不一致的情況？是的，可以，但不能保證。你可以將需求測試的數量乘以一千、一萬、十萬，但這仍然不能保證。成本會激增，但軟件仍然會有錯誤，這些錯誤本可以通過對架構進行測試來避免！現在，底線是：與詳盡的需求測試相比，執行集成測試可以以更低的成本為您提供更健壯的軟件。祝賀你現在理解了這一過程的價值，你是“高端俱樂部”中的一員了！
以下是Automotive SPICE?中軟件集成和集成測試的最重要的三個方面。
5-1 定義軟件集成和集成測試的策略
正如你可能從我們的一些視頻中了解到的，策略是一種易于理解的教學描述。這對于更大的分布式項目尤其重要，這樣所有人都會知道如何做。
該策略首先從一個開發人員的角度描述了軟件團隊的工作流程，他們可以在將軟件交付到團隊工作流之前，執行一些簡單的集成測試。然后團隊可以進行一些集成測試，作為夜間測試運行的一部分。當這些完成后，他們會在將工作交付到項目工作流之前執行一些最終的集成測試。然后可能會有一些額外的集成測試。此外，Automotive SPICE需要“回歸測試策略”。回歸測試僅僅意味著，如果你改變了軟件中的某些東西，你就可以確保所有沒有改變的東西都能正常工作。
一個實際例子是：如果使用持續集成，通常會在夜間測試期間再次運行所有集成測試。所以，策略就是我剛才說的這些。
5-2 為軟件架構提供雙向可追溯性和一致性
可追溯性意味著，對于每個相關的架構元素，例如接口，您可以對應到相應的測試。如果反過來你也能做到這一點（即每個接口測試都能對應到架構中的接口），反之亦然，那么可追溯性是雙向的。
那么一致性意味著什么？在我們前面的示例中，一致性要求接口鏈接到正確的測試（而不是其他測試）。這個測試應該對接口進行完整的測試。如果情況并非如此，則必須鏈接其他測試。一致性還要求測試能夠真正的正確的測試接口。換句話說，沒有差錯的測試。
5-3 總結并交流測試結果
這通常被稱為測試總結報告。這份總結報告應該發送給需要這些信息的人，比如開發團隊、項目經理、質量工程師等等。讓我們仔細看看這份報告應該是什么樣子。顧名思義，它應該總結結果，隱藏不必要的細節。摘要報告應該傳達的主要信息是什么？你怎么認為？當然，它應當符合軟件架構。
Automotive SPICE中的軟件合格性測試過程（也稱為SWE.6）有助于您的組織保證集成軟件滿足軟件需求。
什么是軟件合格性測試？我們期望您已經有了軟件需求，所以我們的目標是對照這些需求進行檢查，并確定它們是否完全滿足并正確實現。
由于該過程是在軟件交付前不久執行的，可以直接交付給客戶，也可以作為系統的基礎，因此與項目管理（MAN.3）、配置管理（SUP.8）、產品發布（SPL.2）等過程有著密切的關系，當然還有軟件需求分析（SWE.1）。
如果軟件合格性測試不能很好地被執行，錯誤可能無法被發現，客戶滿意度也會下降。測試環境取決于產品。例如SIL、PIL或HIL。
以下是Automotive SPICE?軟件合格性測試三個的最重要方面。
6-1 你需要一個明確的測試策略
與所有測試和支持過程一樣，軟件合格性測試需要開發和定義測試策略。對于每個測試級別，您可能需要一個單獨的測試策略，但是最好在所有測試級別上開發和協調測試策略。這可以確保涵蓋所有需求，并避免冗余。
測試策略應涵蓋以下主題：
——有問題的測試對象
——開發測試用例和測試數據的方法（例如，開發正/負測試、等價性劃分）
——回歸測試策略，在Automotive SPICE術語中，這意味著您定義了在錯誤修復或更改請求后要如何重新測試
——測試環境
——與項目計劃和發布計劃相關的測試覆蓋率
——進入和退出標準以及測試中斷標準
當然，這個過程與問題解決管理（SUP.9）有很強的聯系，所以您可以使用測試策略或缺陷管理策略來文檔化如何處理失敗的測試。
6-2 選擇正確的測試用例
這個期望聽起來可能微不足道，但并不是這樣…
該過程希望根據測試目標和覆蓋率，為各種測試選擇測試用例。其目的和期望是，對于不同的交付，根據上述測試策略對軟件進行適當的測試。
這個想法是，你可以有不同期望的交付。策略的一個例子是，您可以完全覆蓋重要交付所有已實現的軟件需求。
對于較小的交付，僅測試自上次交付以來實施的需求增量。
當然，對于這種方法，必須選擇正確的測試用例。選擇測試用例的另一種可能情況是回歸測試，它包括更改請求和/或錯誤修復。這里選擇的測試用例涵蓋了變更請求或bug，以及它們可能產生的影響。后者意味著對可能受變更請求或錯誤修復影響的需求的依賴性也會被測試。
6-3 建立可追溯性和一致性
這個過程還要求您確保軟件測試用例和軟件需求之間的可追溯性。
可追溯性可以通過超鏈接來建立，比如在DOORS中，通過特定的可追溯性工具（比如Rectify），通過可追溯性矩陣，或者通過工具環境支持的其他可管理方式。
可追溯性的目的是：
——支持一致性檢查，即檢查軟件需求覆蓋范圍的完整性和準確性。
——支持變更請求或缺陷情況下的影響評估。
——支持報告利益相關者的期望，并確定哪些需求已經通過測試，通常稱之為覆蓋率報告。
這個要點的第二部分是一致性，在這種情況下，軟件需求和軟件測試用例之間是一致的。如果覆蓋范圍完整且正確，通常會檢查一致性。這只能通過審查（Review）來執行。
如果您無法證明您的軟件已完全正確覆蓋，您可能會發布一個未經充分測試的軟件，因此確保一致性符合您的最佳利益！因此，請確保正確執行此審查（Review）！
[1]Video tutorials and expert talks on Automotive SPICE, functional safety and cybersecurity
[2]kuglermaag.com/automoti
[3]kuglermaag.com/automoti
[4]SWE.3 - System Architectural Design - Kugler Maag Cie
[5]kuglermaag.com/automoti
[6]Get familar with the Automotive SPICE?-Process SWE.5
[7]kuglermaag.com/automoti
聲明：本翻譯稿僅用于學習交流，不得用于商業行為。如有侵權請聯系本文作者進行刪除。
后臺回復：“ECU008獲取ASPICE3.1中文版標準！
閱讀原文，關注作者知乎！
推薦閱讀
談談對兩家AUTOSAR工具看法
奧迪首款800V車型技術總覽
CAN設計與應用指南
汽車軟件需求是如何變成用戶功能？
電子電氣架構設計需要考慮哪些方面？
汽車E/E架構的網絡安全分析
電子電氣架構設計需要考慮哪些方面？
