電子發燒友App
1.介紹
1.1 范圍
ASPICE面對的對象是嵌入式車載系統開發的過程能力。
它提供了兩個模型，一個是PAM過程評估模型，類似于作文競賽的閱卷準則，告訴你基本要素和得分點在哪里，怎么打分，怎么綜合評級；一個是PRM過程參考模型，類似于作文提綱或模板。
為了讓例子的邏輯更貼近ASPICE，多說一句，相當于閱卷準則是一份（比如從主題立意、中心思想、內容結構、語言運用、字跡字體不同得分點進行），但你需要寫多份作文（比如詩歌、散文、議論文、記敘文不同的文體），因為我們的過程不是只有一個。
總結一下，一份閱卷準則+多份不同文體的作文提綱或模板=ASPICE，你基于自己的能力和風格，寫出自己的這多份作文，閱卷老師（ASPICE評估師）來對你的每篇作文進行打分，綜合之后，會給出你每篇作文是幾類文的評級，隨后也可以提出提升寫作能力的建議。
1.2. 術語
這個章節給出了對術語使用應遵循的優先順序：
ISO/IEC 33001、ISO/IEC/IEEE 24765 和 ISO/IEC/IEEE 29119及本標準的附錄C。
1.3. 縮略語
講了常見的縮略語，略。
2.符合性聲明
這個章節沒什么具體內容，就是強調了ASPICE符合ISO/IEC33004，算是表明正統和合法性。
3.過程能力確定
下圖其實是在闡釋ASPICE運行的邏輯，我們還是將其比作是作文閱卷。
橫軸是PRM（過程參考模型），也就是不同文體的作文提綱或模板（各過程類別），比如，詩歌、散文、議論文、記敘文；
縱軸是PAM（過程評估模型），也就是各篇作文基本要素的判定和得分點（過程屬性）的打分，并對你每篇作文是幾類文進行評級（能力等級），比如主題立意切合題意給5分、中心思想明確深刻給5分、內容結構充實清晰給5分、語言運用流暢優美給5分、字跡字體美觀整齊給5分。
具體根據某考生一篇作文的情況，可能會依次打5分、3分、4分、2分、3分之類，多篇作文評定后，最后判斷這名考生的作文水平依次是詩歌三類文、散文二類文、記敘文一類文、議論文0類文，如果所有等級都達到了二類文，我們就會說這名考生達到了本次作文競賽二類文的等級。
就像，該供應商的xxx OEM的xxx項目進行了ASPICE評估，VDA Scope的16個過程域都獲得了二級認證。總聽到有人說，xxx公司獲得了ASPICE L2認證，其實是不嚴謹的，相當于說這個考生是二類文。
3.1 過程參考模型
看這張圖就夠了，這就是ASPICE作文提綱或模板的樣子，比如，ACQ是詩歌，MAN&SUP是散文，SYS&SWE是議論文，其他的是記敘文。
3.1.1 主要生命周期過程類別
這個也不用多講，上圖粉色部分就是主要生命周期過程，我一直覺得軟件的交付和工廠的運營有很多類似之處，這里我們切換為比較直觀的汽車組裝流水線為例。
為了完成一臺整車的交付（軟件最終SOP釋放），我們會有沖壓、焊裝、涂裝、總裝這四大工藝流程，它們或有前后次序，或在并行推進，有的工位要人工操作（工程師人工分析需求、手工編碼、手工測試……），有的設備自動化程度高（數字化工具鏈、基于模型的代碼、自動化的腳本測試……），中間會有半成品的交付（不同成熟度的軟件釋放），不同階段會有不同的QC檢查（集成或合格性測試）……
理念上，ASPICE的這些主要過程也是期望實現自動化的流水線模式，但可能柔性要求更高些，畢竟軟件開發是個智力性、知識性工作。
3.1.2 支持生命周期過程類別
綠色部分被叫做支持過程，對比實實在在的產線設備和人員，顯得有些務虛，但人家顯然也自有其價值，汽車在產線上流動時是需要一些打輔助的東西的。
比如，QA不讓堆料（質量保證）、首件中件尾件尺寸測量確認（驗證）、你的工位上下游及自身都要對部件進行評定（聯合評審）、產線會有作業指導書（文檔化）、每個模塊零件都有對應的追溯標簽（配置管理）、發現漆面劃傷要按不良品流程處理（問題解決管理）、換不同配置模塊時的工裝換型（變更請求管理）。
3.1.3 組織生命周期過程類別
用產線舉例，這塊就可以理解為運營管理，比如生產主管管人保產量（項目管理）、維修經理發現沖壓模具有斷裂風險（風險管理）、隨處可見的不良率指標（度量）、局部工裝換型即可滿足多種車型的生產（重用程序管理）、很多工廠會有合理化建議提交流程（過程改進）。
其實，我們會發現機械和和軟件并不分家，有很多類似之處，軟件工程似乎有很多可以向傳統制造業學習的地方。
3.2 度量框架
這部分就是前面所說的作文競賽閱卷準則里的評分細則，我們可以在后面具體內容上詳看。
3.2.1. 過程能力級別和過程屬性
這里給出了如標題兩個概念，過程能力級別就是這名考生的各篇作文是幾類文；過程屬性就是得分點，適應于所有文體。
根據ISO/IEC 33020，共有6個能力級別（6個作文等級），包含9個過程屬性（9個得分點），見下圖。
?
3.2.2. 過程屬性評定
搞清楚了得分點，就要考慮得分點到底怎么打，怎么樣是1分，怎么樣是5分呢，畢竟作文不是數學，靈活性更大，這得分點評分分的細則就是這ASPICE里的“評定尺度”，且看下圖。
?
從描述可以看出來，這個評估尺度的把握更多是一種經驗、直覺、感覺，而非量化的。
此外，標準也給出了如何評定的方法建議，但實在是佶屈聱牙，十分費解。
我覺得可以這樣去理解，實際的項目開發很難清晰地區分出不同流程的界限，肯定是你中有我，我中有你，比如，測試和缺陷、需求和設計、項目管理和質量保證……都會糅合在一起。
簡言之，這方法就是要綜合考慮，綜合考慮過程的定義、過程達成的結果、各個過程之間的關系，好似一句廢話，但這其實就是這項工作的特點。
我想，ASPICE也盡力描述了，就像PMBOK里有句話這樣寫的，“雖然在本《PMBOK 指南》中，各項目整合管理過程以界限分明和相互獨立的形式出現，但在實踐中它們會以本指南無法全面詳述的方式相互交疊和相互作用”，算是給一個免責聲明。
3.2.3 過程能力等級模型
這個直接看圖，大概是什么意思呢？
相當于是二類文只看主題立意是不是跑題、中心思想是否明確……但五類文要從主題立意、中心思想、內容結構、語言運用、字跡字體多個方面來看。
越是低等級的文章，得分點越少，因為低等級文章沒有，但滿分作文得是要全方位評價了。當然，實際習慣里，一類文是最好的意思，恰好和ASPICE評級順序相反。
具體的細節會在后面章節展開。
3.3 過程評估模型
過程評估模型定義了兩種指標：
過程實施指標，其只適用于能力級別1級，提供了過程成果實現程度的指示，相當于閱卷準則里給出的作文模板或提綱的基本成文要素是否滿足，比如，詩歌要押韻、散文要抒情、議論文要有論點論據論證、記敘文要有時間地點人物，不是殘篇，完整成文后可算是等級1。
過程能力指標，其適用于能力級別2級到5級，它們提供了過程屬性成就實現程度的指示（得分點的描述）。這就是說在達到最基本的成文標準1級后，就可以根據其踩到多少得分點進行更高等級的評定。
當然，ASPICE評估不像批改作文，對著那幾篇文章看就好了，ASPICE評估主要是針對過程的工作產品進行檢查，或者對過程執行者和管理者所做的陳述進行評估。
解釋了這個指標的概念，接下來看看更細節的描述。
3.3.1 過程實施指標
過程實施指標的類型為：基本實踐（BP）和工作產品（WP）。
BPs和WPs都與一個或多個過程成果相關。因此，BPs和WPs總是過程特定的，而不是通用的。BPs代表面向活動的指標，就是過程里一步步的活動，ASPICE認為是基本的、必要的部分。WPs代表面向結果的指標，是一個過程的輸出結果，或者叫交付物，比如你的代碼、架構書、測試報告等。
這里強調了一點，標準里的WPs不是“嚴格的必須”，應該由具體的項目或組織自行定義模板或方式，ASPICE告訴你這樣做挺好，但好的方式有很多種，要尊重并鼓勵多樣性。
3.3.2 過程能力指標
過程能力指標的類型為：通用實踐（GP）和通用資源（GR）。
GPs和GRs是與一個或多個PA（得分點）的達成相關的。然而，與過程實施指標相反，它們是通用類型，即它們適用于任何過程，就像字跡優美是所有文章的得分點。當然，為了結構完整，ASPICE在等級1里也增加了PA1.1的GP1.1.1，算是對過程實踐指標的一個概述。
GP和GR的區別在于，前者是面向活動的指標，相當于論點本身是否立意高遠，而后者是面向基礎設施的指標，我們用到的工具鏈就屬于這個范疇。
下面依次放了這么張總結圖，供參考理解。
3.3.3 理解PAM的抽象級別
原文描述了過程評估模型、方法和執行的關系，有興趣的可以查看。
我們還是按照閱卷這個思路來理解，閱卷準則（過程評估模型）告訴你什么是“好”文章，寫作目標是什么；寫作方法（方法）是指導你如何去寫一個論點，如何描述一個人物；敲鍵盤或寫字（執行）就是具體寫作的過程。
反過來的話，你寫了一篇文章，別人看你文章總結或你自己總結出一些方法，但這方法可能適用你卻不完全適用于別人，這就是為什么要裁剪，為什么要結合公司實際業務確定流程體系。
閱卷老師看你的文章，根據閱卷準則搜尋得分點，并按照評分細則給分，最后得出你的文章分數，定出了你的寫作能力等級，這就是ASPICE評估的過程。
4.過程參考模型和實施指標（等級1級）
上面寫了ASPICE3.1的前三章節，講了ASPICE的基本運作邏輯。
今天接著寫第四章，就是我們所說的作文提綱或模板（參考模型：3個過程類別，8個過程組，32個過程），它同時也引出了作文所需要的基本要素（實施指標：BP和WP），就像議論文的論點論據論證都要有，也沒跑題，達成完整成文的目標后算是1級，所以叫基本實踐。
我們回到標準，下圖顯示了過程描述的樣子（作文提綱或模板），以下所有子章節描述的8個過程組都是一樣的結構。對照我們實際工作，這就是描述了一個流程，你要做什么、為什么這么做、做到什么程度及輸出什么成果。
既然是品讀，我們也不必把原文都謄上來，具體的細節可以直接查閱標準，文章里側重于摘出實踐中的關鍵信息。
4.1 獲取過程組（ACQ）
這個ACQ被翻譯成了獲取，但業內習慣叫法是報價，基本都是發生在新項目報價時的OEM對Tier 1或者Tier 1對Tier 2，也就是客戶與供應商。
一般來說，客戶采購會通過供應商銷售這個口子將詢價的各類需求（比如叫RFQ或SOR之類）送達，并限定報價時間。
銷售呢，轉手將相關文件分發給工程、工廠、物流等角色去分析，各個責任人與客戶或內部采購或供應商對應接口將方案、風險等確認后，再協同對應部門的成本一起匯總給銷售，銷售綜合之后，向客戶報價。
這是個簡單的理論路徑，實際上，報價階段項目組介入不多，參與者多是銷售或項目經理等少數人，流程也不會非常規范，會有各種操作。
4.1.1 ACQ.3合同協定
當走到這一步，前期工作基本做得差不多了，要準備定點給這家供應商了，后續要走商務合同的簽署，明確好雙方的權利與義務，也就是本節所謂的“合同協定”。
商務合同涉及到法律條文，所以多數是定式，修改里面部分項目信息即可，但是在報價階段形成的和與項目相關的技術協議、技術方案、各類承諾文檔乃至郵件，其實都是可以作為合同的附屬物來約束雙方。
甲方爸爸的威嚴和乙方孫子的掙扎很多時候需要臺面上的這些東西來維護和推進。
商業社會，項目經理或銷售都需要有敏感的法律和契約意識，郵件不亂發，字不亂簽，話不亂說。
盡管合作成熟的甲乙方不怎么會對簿公堂，但“扯皮”是極為常見的，因為某方亂承諾或沒有留好證據，導致自己陷入被動和膠著是非常常見的。
4.1.2 ACQ.4供應商監控
監控這個詞放在汽車行業的語境里是不夠精準的，其實就是日常項目開展中，客戶對供應商的管控。
比如，根據客戶行業地位的高低和前期的約定，進行開會盯、評審看、電話催、微信問、郵件投訴各類常規操作，就是客戶要想辦法讓供應商按時保質地完成他的各種要求，包括但不限于上一部分的合同協議涵蓋的內容。
4.1.3 ACQ.11技術需求
需求與技術需求這兩個概念本身都不復雜，但后面章節還專門細分了系統、軟件需求，所以這里的需求實際上更側重于報價階段宏觀的、描述性的、概要的需求定義。
理論上或期望上，我們追求在報價階段就將需求范圍鎖定，做什么，不做什么，什么時候做，一清二楚。顯然，又是不太可能的，一來報價階段持續時間很短，介入的人不太容易涉及到各方專家；二來這個階段的很多信息還不清楚，無法做決定。
風險和不確定性一定存在。
那么，怎么做呢？其實，就是基于經驗、項目復雜度及重要程度，關于到底帶多大的風險而進行的權衡。
如果面對相對成熟的或重要級別沒那么高的項目，會使用參考或假設的描述，比如，對于尚不清晰的部分，可以說基于某款量產的整車空間和某款量產ECU的技術要求，增加某項功能，參數范圍是多少，并按照哪一標準完成實驗，如后續有超出的范圍，另行談判……通過這樣的方式，框定一個范圍，并留有一定的余量，雖說帶一些風險，但后期總是有辦法吃掉的。
但如果面對的是新型的或很重要的項目，可能會引入更多的職能角色進行更細致的分析，結合歷史LLs和新的要求考慮得更全面，盡量避免難以掌控的情況出現。
4.1.4 ACQ.12法律和行政要求
這個屬于項目紅線，相關角色要繃緊神經。
一般涉及到出口國家的法規、認證、運輸等各類需求，或者本國的法律、行業的強標以及專利侵權的一些考量。
比如，有些產品受到政治限制是無法出口到伊拉克之類，或者型式認可（上公告）需要特定狀態的產品，或者UI文言涉及到國家主權之類的……
4.1.5 ACQ.13項目需求
這部分包羅萬象，除了技術的、法規的、資質的等特定需求部分，其余所有需求都可以劃歸到這里，所謂萬事皆可項目，萬事不離項目，萬事都可找項目經理。
具體來說，要看具體的產品特點和以往項目的運作模式，雙方的項目接口人員與內部團隊在共同協定下，定義好怎么推進問題、怎么跟蹤進展、怎么分配任務、怎么劃分職責、怎么溝通交流、怎么交付軟件或樣件、怎么付款、怎么進行風險或缺陷管理、安排什么資質的工程師……
期望的做法是不僅僅停留在口頭上和不正式的臨時約定上，要落實成規則、流程。
4.1.6 ACQ.14提案要求
在汽車行業，將其粗略理解為RFQ或SOR包更好些。
采購發包時會將很多需求包含在內，除了前面提到的項目、技術、財務、人力、法規之類，報價本身也會有一些特殊的要求，可能會對R&D成本有特別的拆分需求，可能會有多家供應商競標的要求，可能會有供應商能力評定的要求，可能會有售后支持的要求……
標準里的描述很寬泛，僅僅給了一個概念上的框架。實際操作中，會有不同的類別的要求通過該階段發布給競標供應商。
4.1.7 ACQ.15供應商資質鑒定
這和ASPICE、16949以及所有考級或認證的考試或評定一樣，在建立好的一套評估體系里給它打個分、劃個級別、貼個標簽，以便于后續選擇時作為參考。
采購部門里一般會有供應商的庫，可能會有不同的標簽標記，比如紅黃綠或者首選次選之類。
然而，無論如何，供應商資質只是一個很低的門檻，選定一家供應商有諸多無法盡述的明暗規則。
4.2 供應過程組（SPL）
4.2.1 SPL.1供應商投標
這里不作詳述，因為這部分和ACQ實質上是混雜在一起的，招標與投標是協同做一件事情。
4.2.2 SPL.2產品發布
換句話說，產品發布就是供應商將樣件或軟件交付給客戶的過程。
在此過程中，會涉及到軟件版本號定義、樣件標簽定義、供應商內部批準、Release Note編制、測試報告提交、客戶認可……一系列管理過程，目標是將客戶需求的軟硬件正確及時地交給客戶。
4.3 系統工程過程組（SYS）
系統工程和軟件工程組的整體思路是從需求、設計、驗證三個角度逐級拆分并形成追溯對應的層次化，從客戶一句話到一段代碼，顆粒度越來越小，做得越來越精細。
就像做十字繡，從想要“家和萬事興”的一句話，到一張布畫出很細碎的格子，再到明確每個格子誰來用什么線與什么針法。格子越細，越容易標準化，越容易分工，出錯的概率越低，難度越低，越容易重復成功。
4.3.1 SYS.1需求挖掘
需求是我們開展項目的目標，所謂目標導向，就是需求導向。
這里所講的需求不僅僅限于客戶需求，是指所有相關方的需求，領導的、工廠的、采購的、銷售的、開發的、測試的……也會以各種形式存在，明示的、暗示的、文本的、郵件的、微信的、電話的……總之，所有有關系的人的想要的都要被考慮到，只是有些不那么重要的人的需求往往被忽略和平衡掉。
需求挖掘的幾個核心點是要溝通、要理解、要達成一致，而后要持續跟蹤、變更要被管理、是否實現要定義清楚等。
4.3.2 SYS.2系統需求分析
在識別出各位想要什么之后，不是滿口答應，而是要去分析，要看它們對不對、能不能驗、能不能做、值不值得做，還要將上一階段相對雜亂的需求整理，進行結構化和優先級排序，要確保把相關方的需求很好地梳理了出來，形成了清晰、層次分明且不遺漏的技術語言。
4.3.3 SYS.3系統架構設計
要什么清楚了，然后就是設計，這步是架構的設計，比如要形成架構框圖、接口定義、時序圖等，還要進行與需求的追溯。相當于你要裝修房子，店家給你弄了個效果圖。
4.3.4 SYS.4系統集成與集成測試
從技術上來講，系統集成就是根據BOM在硬件上刷新軟件，并搭建好相關的整車或網絡環境等。集成測試的目標是確認架構對不對，可能會關注到系統組件之間的正確信號流、信號流的時效性、時序依賴性、接口的動態交互等。
4.3.5 SYS.5系統合格性測試
系統合格性測試也叫系統測試或者系統需求測試，就是看看系統需求有沒有做到位。
4.4 軟件工程組（SWE）
4.4.1 SWE.1軟件需求分析
軟件需求和系統需求類似，就是將上一層級的系統需求與系統架構再細分為更貼合編碼的軟件需求語言。
4.4.2 SWE.2軟件架構設計
架構設計呢，也就是針對最后一層的需求——軟件需求，進行的方案和架構設計。
4.4.3 SWE.3軟件詳細設計和單元構建
根據架構劃分的模塊，軟件開發人員就可以進行詳細的編碼設計，會形成一個個的可執行文件。
4.4.4 SWE.4軟件單元驗證
軟件單元設計完后，依然需要驗證，只不過這里更多是針對本身設計合理性進行的，比如靜態分析、依照編碼規范的檢查等。
4.4.5 SWE.5軟件集成和集成測試
將一個個可執行的單元文件集成到符合軟件架構的完整的集成軟件，而后進行集成測試，以確認其是否符合軟件架構設計。
4.4.6 SWE.6軟件合格性測試
同系統測試類似，也就是針對軟件需求進行的測試。
4.5 支持過程組（SUP）
4.5.1 SUP.1質量保證
特別是在國內環境下，這個角色其實一直處于相對比較尷尬的境地。
理論上的定義是，作為獨立第三方去保證工作產品（不單單是軟件產品，還包括其他各類要交付的文檔等）和流程符合規定和計劃，但達到這個目標的前提是有脫離于具體場景的標準（即不是具體問題具體分析）和執行標準的文化，顯然這很難具備。
ASPICE似乎也意識到了，所以有這么兩句話“建立了將不符合項升級到適當管理層的權限“和”管理層確保已升級的不符合項得到解決”，但這兩條里提到的管理層多數并無這樣的認識。
“實事求是”、“具體問題具體分析”、“成王敗寇”是中國的經典智慧，但執行起來就是給質量保證工作當頭棒喝，如果事情以結果論英雄，凡事可討論，質量保證很難有發揮空間。
不過，到什么山唱什么歌，什么環境按照什么樣的方式做事，這個角色依然可以拓展到不同的領域。
4.5.2 SUP.2驗證
這里的驗證和軟件的測試是不同的概念，它具有更廣泛的涵義，是指對確認每個工作產品是否滿足定義的要求的行為，包含但大于測試，比如，同行評審、領導簽字、第三方審核等。
4.5.3 SUP.4聯合評審
這個概念單獨拿出來，其實是側重于整體的項目狀態和多個相關方的需求滿足得如何的確認，所謂聯合就是整體，所謂評審就是確認。
大家一起理理清，對對齊。
對照實際的工作，基本可以等同于質量組織的各個里程碑的質量閥評審，這部分也是質量保證工作難得的發聲場景。
4.5.4 SUP.7文檔化
標準定義的目的是“開發和維護由過程產出的記錄信息”，關鍵詞在“信息”，盡管大家往往比較反感這部分工作，但至少截至目前，我們找不到更好的信息傳遞的方式，數字化可能能解決一部分傳統文檔化的弊端，但由于其工具使用有一定的門檻、編輯展示不夠靈活、未足夠普及、技術尚未成熟等不足，并不能取代文檔。
無論是敏捷變更也好，還是數字化轉型也好，文檔的優化都是一大課題，后續我們可以繼續思考探討。
4.5.5 SUP.8配置管理
關于配置管理，我們前面寫了好幾篇文章，這里不贅述了。
4.5.6 SUP.9問題解決管理
問題包括軟件缺陷或其他項目相關問題，總體要求是要有特定ID、來源、發生階段、嚴重或緊急等級、發生場景、發生版本、原因分析、解決方案、責任人等。
由于軟件缺陷動輒幾百上千，所以缺陷的管理流程是相對規范的，而且缺陷基本代表了軟件產品的狀態，相應地，受到的關注度也比較高。
后續我們會出一篇文章詳細寫一下缺陷管理。
4.5.7 SUP.10變更請求管理
變更是個老生常談的話題，變更本身不具備特殊性，實際上會驅動一次簡化的或完整的開發過程。
其中的關鍵點在于，變更要經過預先可行性分析和CCB上是否執行的批準。
4.6 管理過程組（MAN）
4.6.1 MAN.3項目管理
ASPICE并沒有將項目管理講出什么花樣來，權威的論述還是要看項目管理寶典PMBOK。
這里其實想分享點對項目管理另外的看法，如果要挑選出前三點，一個好的項目經理最需要的素質是：積極的溝通、很強的抗壓能力和全面的業務邏輯。其余呢，要靠經驗積累了。
4.6.2 MAN.5風險管理
每次看到風險管理，總有種無語的感覺。除了比較流行的FMEA、FTA等工具，常規的項目經理維護的那個風險管理表格，確實有種應付交差的樣子。
真正的項目推動，可以靠開口項，可以靠缺陷管理，可以靠變更管理，唯獨風險，著實難以獨立落地，并不是不存在，而是都融合到了其余環節，比如，識別出什么風險后，會首先定義相關的調整任務，而不是去做一下風險管理。
當然，有時候需要匯報項目狀態時，或者做一個什么決策選擇時，也會用到這個概念。
4.6.3 MAN.6度量
度量離不開數據，數據離不開真實、及時和完整。
這也是比較難做到的，但聊勝于無吧，越是關鍵的判斷和決策越會關注數據的有效性。
前兩天看了馬云的一個演講，特別提到了數字化和數據在未來的重要性，這值得我們所有從業者認真思考一下這個課題。
4.7 過程改進過程組（PIM）
4.7.1 PIM.3過程改進
過程改進是個很有價值的點，最有機會的人是前線戰斗的人，但這批人往往沒動力，反正一個項目交付了就好了，所以這部分常會淪落為EPG自嗨的領地。
這很需要制度來驅動大家的積極性，最直接的是通過錢來鼓勵大家動起來。
4.8 重用過程組（REU）
4.8.1 REU.2重用程序管理
這個概念和平臺化與共享化很接近，核心在于如何最大化利用現有資源。
對于汽車行業軟件開發，相當于裁剪，針對不同復雜度的項目，將部分活動進行裁剪，主要也就是進行復用或重用，比如A項目的某些測試結果可被B項目拿來重用等。
5.過程能力等級與過程屬性
總算寫到最后一部分了。按照前面的承諾，這篇我們會根據文章的得分點（過程屬性）逐層遞進到滿分作文（等級5），看看是什么樣子的，也就是ASPICE眼里的最高水平。
5.1 過程能力等級0級：不完整的過程
“過程未實施、或未能實現其過程目的。在這個等級只有很少或沒有系統化實現過程目的的證據”。
也就是說，第4章節提到的那些基本實踐都未完整做到，沒能達成最基礎的項目工作目標（ASPICE認為的），就像文章不滿400字或議論文沒論據，定為殘篇，直接低類文，甚至價值觀不正，零分走起。
要是嚴格按照ASPICE的思路，實踐上很多公司在不做準備的前提下直接迎審，就是0級。
5.2 過程能力等級1級：已執行的過程
“已執行的過程實現其過程目的”。
5.2.1 PA 1.1過程實施過程屬性
“過程實施過程屬性是衡量過程目的實現程度的一種度量“。
前面我們也提到過，這第一個得分點其實是對基本成文（基礎實踐）的一個整體描述，本身不是一個獨立的點，只有達到了這個條件，才有資格進行好文章的評定。
換句話說，就是目的導向，做成功了。不管白貓黑貓，反正抓到耗子了。
這其實是蠻有意思的，一般理解里，以目的為導向，以成敗論英雄，似乎沒什么問題，有時候甚至還被認為是至上哲理。ASPICE不這么認為，它認為這只是最低要求。在這里，大家可以感受下ASPICE的思路，后面會逐漸展開。
5.3 過程能力等級2級：已管理的過程
我們進入到了文章水平判斷的第二階段，批改老師們開始正襟危坐看細節，開始抓真正的得分點了。
“以管理的方式（計劃，監控和調整）來實施前述的已執行的過程，并且適當的建立、控制和維護該過程工作產品。以下過程屬性與先前已定義的過程屬性一起來證明本級別的達成“。
目標達成了，我們要看是怎么達成的，是瞎貓碰到死耗子，還是有“預謀”（以管理的方式）地抓到的？
5.3.1 PA 2.1實施管理過程屬性
“實施管理過程屬性是對過程實施進行管理的程度的度量”。
這個得分點怎么理解呢？
我們拋開那些冗長的描述，最關鍵的是要提前做好統籌規劃，搞清楚對方要什么、排好什么時間做、定好誰來做、需要什么資源（如設備、樣件等）、定期或不定期的會議或工具跟蹤、跟蹤到異常及時調整計劃……
實際上，這是管理一個項目或一件事項的基本要求，做得不好的呢，就是做到哪算哪，碰到啥問題，臨時救火。
5.3.2 PA 2.2工作產品管理過程屬性
“工作產品管理過程屬性是對過程生成的工作產品進行適當管理的程度的度量”。
同樣是管理，上一個側重于整體的“做”的規劃管理，這個是側重于“做出來的東西”。前者更傾向于項目經理視角，到點拿到東西；后者更傾向于職能經理視角，要確保做出來的東西被良好管理和正確交付。
工作產品是一個比較抽象的描述，我們舉個具體點例子，比如客戶要求交付測試報告，我們要按照客戶的要求，去用特定模板結構，選擇專屬用例，做好版本命名，在變更履歷里做好記錄，完成評審修改，并通過專門的工具進行發布和存檔等。
更便于理解的方式是三個詞：基于需求、文檔化（含配置管理）、評審。
這個級別重點在管理、在受控，而不是隨機成功。
5.4 過程能力等級3級：已建立的過程
“先述的已管理的過程，由能實現其過程成果的已定義的過程來實施。以下過程屬性結合先前已定義的過程屬性，證明達成該等級” 。
二級貓是有“預謀”地抓耗子，三級貓是要基于貓群里已經定義好的流程去抓耗子，不是僅僅腦子里的“預謀”。
5.4.1 PA 3.1過程定義過程屬性
“過程定義過程屬性是維護標準過程以支持已定義過程的部署的程度的度量”。
簡言之，就是有詳細的流程定義。比如經常用到Stages來配置整套的過程體系，一般會定義活動的前后次序、不同過程之間的交互、負責人、所需的工具等，整體組成可能包括畫出來的流程框圖、每個活動的具體描述與相關角色定義、輸入與輸出的工作產品，以及對應的指南或培訓材料等，還有很關鍵或者很理想的一點是，需要有量化指標來評價標準過程的有效性和適用性。注意，這里和MAN.6的度量不一樣，這里是評價過程好不好使，而MAN.6的度量本身就是一個過程，是看度量的對象好不好。
5.4.2 PA 3.2過程部署過程屬性
“過程部署過程屬性是，對標準過程作為已定義過程進行部署而實現其過程成果的程度的度量”。
在PA3.1的書面定義之后，就是在具體項目的落實了，也就是本節所講的。
首先呢，我們在開展一個項目之前會進行裁剪，畢竟不是所有的項目都需要完整跑一趟全流程，裁剪就是定義本項目所要遵守的流程規范。
接下來，要安排相關的人員，如能力不足，還需要組織培訓，并且準備相關的資源（如線束、臺架等）或工作環境（如工具系統里開出一個項目區域）等。
隨后，還要不斷收集分析相關數據，評估過程是不是確實有用（不是運作得符不符合標準過程），如有問題，要進行流程改善。
這一步的邏輯很清晰，就是按流程落實，但往往在這一步會回退到結果導向的模式。
5.5 過程能力等級4級：可預測的過程
“先述的已建立的過程，在定義的限值內可預測地運作以達成其過程成果。識別量化管理需要，收集和分析度量數據，以識別波動的可查明原因。采取糾正措施來解決波動的可查明原因。以下過程屬性結合先前已定義的過程屬性，證明達成該等級”。
這句話是指說什么呢？三級貓可以達到按流程抓到耗子，四級貓是有了更高的智慧，調用歷史耗子作息規律和行進軌跡的數據庫進行數理分析，能預測出幾點到哪兒抓幾只耗子了。
目前，據說只有德國博世平臺達到了這只貓的水平（如有錯漏，請指正）。
5.5.1 PA 4.1定量分析過程屬性
“定量分析過程的屬性是，定義信息需要、識別過程要素之間的關系以及收集數據的程度的度量”。
歸根結底，ASPICE制定者想在這個級別達到量化的因果鏈條實現的管理，企業的終“果”是商業目標，所以第一個GP就是識別商業目標。
除商業目標之外，還有各利益相關方的需要也要被考慮到。此外，還要關注到不同過程要素之間的關系。
基于這些目標，來定義定量的目標和支持這目標實現的細化度量項。隨后，就是進行數據收集和度量項的分析，并將這過程、項目、產品的結果提供給相關的人。
5.5.2 PA 4.2定量控制過程屬性
“定量控制過程屬性是對客觀數據被用于管理可預測的過程績效的程度的度量”。
“定量分析過程屬性”相當于是只是給出來結果和限值，“定量控制過程屬性”是要用這結果管理項目。比如，定量分析出來迭代速率和缺陷逃逸率，但光看這倆數字不知道意味著什么，就需要進一步利用一定數理統計方法或工具及業務理解來處理這結果，建立過程績效分布，確認波動原因，并進行糾正。
如果這樣不是很好理解，想一下機械產品的控制圖（判斷過程是否處于穩定所使用的帶控制線的圖），就很容易理解了。
寫到這里，會發現什么呢？所謂定量，需要一個基礎，那就是低變差、高標準。這又和那個提了幾十年的“軟件工廠”理念類似。
盡管現實項目里很少見到這樣的實踐，但還是思考一個問題，四級能實現嗎？
基于機械產品大批量量產的成功經驗，我想是能實現的。但是，有必要實現嗎？或者實現后有價值嗎？暫且留一個開放問題，一起思考下。
5.6 過程能力級別5級： 創新的過程
“先述的可預測的過程得到不斷地改進，以響應與組織目標一致的變化”。
這下更厲害了，終于到我們滿分作文了。不過，作文這個比方在這篇文章不太恰當，不太有助于理解，所以還是用貓抓耗子的例子。
四級貓會數學，五級貓就更神了，但也很不容易，這只貓發現耗子千變萬化，甚至受“市場”影響，還得抓小雞，它需要一系列的方法創新。
5.6.1 PA 5.1過程創新屬性
“過程創新過程的屬性是，從對過程的定義和部署的創新方法的調查中識別過程變化的程度的度量”。
這里比較簡單了，一句話總結，基于新的商業愿景，在領導堅定擁護創新的前提下，分析現有數據和新技術、新概念識別創新機會。
5.6.2 PA 5.2過程創新實施過程屬性
“過程創新實施過程屬性是對過程的定義、管理和績效的變化達成相關過程創新目標的程度的度量”。
這個冠的名號依然不小，實際就是基于PA5.1的流程變更管理，比如進行影響分析、執行、評估變更有效性。
到這里，看清楚了這滿分作文或五級貓的真面目，有沒有感覺有些失望？
我是有些失望的，我認為4級甚至3級的實現就沒有了5級的土壤。可能也是ASPICE比較雞賊，為了讓自己生命力久一點和適用場合廣一點，加了這么個級別，畢竟你再發展也需要創新啊。
說在最后
總結下我對ASPICE的認識。
ASPICE算是軟件工程和項目管理的良好實踐總結，特有的精華都在第4章的過程參考模型里，是一個系統且細化的軟件工程化模型。
而所謂的評級，是針對成熟度的，而非優秀度，也就是說成熟不等于優秀，即并非級別越高越好。
一定程度上，1到5級基本映射了行業或業務的發展軌跡和需要，不同發展階段會落在對應級別，但也可以說這個階段需要這個級別所描述的運作模式，更高的級別不適合它。
也就是，初生混亂無序的0級；需要敏捷探索與目標導向，并能偶然成功落地的1級；積累了一定的成功經驗，從而可被管理，并逐漸進入穩定有序的2級；技術日臻成熟，市場顯現壟斷，標準也明確且統一的3級；進入存量市場，需要高標準、高效率，甚至打價格戰的4級；盛而入衰，不創新不求變就得死的5級。
審核編輯 ：李倩
工商網監
評論