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級。

,