SUP.8 Configuration Management 建構管理

ASPICE 標準解讀: 支持流程

Published in

ASPICE標準解讀

4 min readJun 23, 2020

目錄: Automotive SPICE(ASPICE)標準解讀 / 支持流程SUP.1: 品質保證
SUP.2: 驗證
SUP.4: 聯合審查 
SUP.8: 建構管理 
SUP.9: 問題解決管理
SUP.10: 變更管理

流程目的(Process Purpose)

The purpose of the configuration Management Process is to establish and maintain the integrity of all work products of a process or project and make them available to affected parties.

建構管理流程的目的是建立和維持一個流程或專案的所有工作產出的完整性，並將其(所有工作產出)提供給受影響的單位。

額外說明 - Configuration Management作者在這邊所使用的翻譯為「建構管理」，另外讀者也會常聽到「組態管理」、「設定管理」或「配置管理」等。在一般的產品生命流程中(研發加上生產)，常常會需要管控人機料法，在這個概念下我們會需要管理機器的設定，料件的配方，方法的定義，在這種情況下的這些「設定」(Configuration)，可以被理解成「組態管理」、「設定管理」或「配置管理」。然而，在ASPICE中，我們是處於一個研發的階段，所有的檔案、文件、產出，最終會被串聯起來，跟最後發布的產品形成一個版本。因此，這邊的翻譯偏好使用「建構管理」

流程結果(Process Outcome)

成功實作建構管理流程，其相應的結果如下：

[Outcome 1]制定一份建構管理策略；
[Outcome 2]流程或專案所產生的建構項目，將根據建構管理策略，進行識別、定義和基準處理；
[Outcome 3]控制建構項目的變動與發佈；
[Outcome 4]修改或發佈提供給受影響方；
[Outcome 5]紀錄與回報建構項目的狀態；
[Outcome 6]確保基準的完整性與一致性
[Outcome 7]控制建構項目的儲存

基礎實踐(Base Practices)

SUP.8.BP1: Develop a configuration management strategy.
SUP.8.BP1: 制定一個建構管理策略
[Outcome 1]

Develop a configuration management strategy, including

responsibilities;
tools and repositories;
criteria for configuration items;
naming conventions;
access rights;
criteria for baselines;
merge and branch strategy;
the revision history approach for configuration items

制定一個建構管理策略，包含：

權責
工具和資料庫
建構項目的條件
命名規則
存取權限
基準的條件
分支與合併的策略
建構項目的修訂歷史記錄方法

NOTE 1: The configuration management strategy typically supports the handling of product/software variants which may be caused by different sets of application parameters or by other causes.
NOTE 2: The branch management strategy specifies in which cases branching is permissible, whether authorization is required, how branches are merged, and which activities are required to verify that all changes have been consistently integrated without damage to other changes or to the original software.
備註1: 建構管理策略通常支援產品/軟體變動的處理，這些變動可能是由不同的應用程式參數所導致或其他原因。
備註2: 分支管理策略詳細說明在何種情況下允許分支、是否需要授權、分支如何合併、以及需要哪些活動來驗證所有變更是否整合一致，而不損壞其他變更或原始軟體。

這一個條文，要額外說明的部分較多，因此條列如下：額外說明(1) -- 資料庫(repositories)一般來說，repositories翻譯成資料庫，但是在建構管理流程，這邊的意思偏向資料存放的結構，例如：如果要將資料存放在公司的雲端資料夾，存放的路徑，資料夾的結構如何等等。有些資料不見得是檔案的形式，例如：客戶需求、系統需求、軟體需求，將透過OOO工具裡面的專案路徑進行存放管控；又或是，軟體開發中的程式碼，這類型的檔案通常是透過GIT或SVN來進行管控。因此，這裡提到的資料庫(或資料結構)，指的是要針對這個專案的需求，定義不同建構項目的管理與存放的路徑與工具。值得一提的是，條文中所提到的存取權限，亦是針對不同的資料夾結構及工具來控制。--
額外說明(2) -- 建構項目的條件(criteria for configuration items)關於「建構項目的說明」，請參考BP2的額外說明。這邊先針對建構項目的條件來進行說明，一般來說並非專案的所有建構項目都透過同一種方法來管控，因此常見的管控方法，可以條列成以下：
1) 基準控管
2) 版本控管
3) 儲存控管其中，版本控管又分成兩種，一種是只進版但不允許內部變動，例如：客戶需求、業界標準、等；另外一種是允許內部變動，例如：時程、程式碼、等。--
額外說明(3) -- 基準 及 基準的條件先來說明一下基準是什麼，首先先來看看IEEE的定義：a baseline is a specificaiton of product that has been formally reviewed and agreed upon, and that thereafter serves as the basis for further development, and that can be chagned only through formal change procedures. 基準是經過正式審查且核准的產品規格，其後被用來做為進一步開發的基礎，只能透過正式的變更程序才能進行變更。在開發過程中，將會有很多的重要規格文件，由於ASPICE開發流程定義為V-model，因此這些規格文件均是下一階流程的發展基礎(例如: SYS.2的產出--系統需求規格書，將是SYS.3的發展基礎)。這些規格文件，可以被視為建構項目(通常包含：規格書、設計書、測試規格、程式碼、makefile、文件、圖檔、等)，每個建構項目都有其版本。隨著專案的進展，這些規格文件將會陸續的產出，或是不斷的修正導致版本進版。而所謂的基準，就是在重要的時間點，將當下所有的建構項目做一個快照(Snapshot)。基於上述，可以發現兩件事情：
1) 在重要的時間點，必須要做基準
2) 建構項目要變成基準必須滿足一些條件因此，基準的條件指的便是上述的兩件事情，在建構管理策略中，必須要詳訂
1) 基準的時間點，基本上會參考專案的生命週期
2) 建構項目能夠成為基準的條件，如同IEEE的定義，必須是重要的建構項目，其次該建構項目需要被審查且核准。(如何知道是否是重要的建構項目呢？在ASPICE的標準中，則是透過BP2來識別)

—

SUP.8.BP2: Identify configuration items.
SUP.8.BP2: 識別建構項目
[Outcome 2]

Identify and document configuration items according to the configuration management strategy.

根據建構管理策略，識別與紀錄建構項目。

NOTE 3: Configuration control is typically applied for the products that are delivered to the customer, designated internal work products, acquired products, tools and other configuration items that are used in creating and describing these work products.
備註3: 建構控制通常應用於交付給客戶的產品、指定的內部工作產出、獲取的產品、工具以及用於創建和描述這些工作產出的其他建構項目。

額外說明 -- 建構項目 VS 工作產出工作產出(Work product)是依照ASPICE標準的BP執行後，應該要產出的項目；在實際專案進行中，實際產出的檔案，我們稱之為建構項目(Configuration Item)。如下表所示，右邊的部分是工作產出，而右邊的部分則為建構項目，對照兩邊，讀者應該不難看出這兩者之間的關係。其中，筆者針對以下三種狀況，再詳細的說明：1) 1:1關係：WP與CI為一對一的關係，如同第一個項目所示，MAN.3中應該要產出一份專案計畫書，而實際專案執行也產出一份專案計畫書。2) N:1關係：WP與CI為多對一的關係，如同第二個項目所示，MAN.3為專案管理流程，該流程必須定期的監控專案的狀態，並且需要跟團隊成員進行溝通，在這個範例中，讀者可以看見每個星期的會議紀錄檔案，都是所謂的溝通紀錄。3) 1:N關係：WP與CI為一對多的關係，如同第三個項目所示，SUP.8為建構管理流程，在實際開展建構管理工作時，必須要先進行規劃，規劃需要考慮的面向除了包含建構管理策略之外，亦包含(檔案)復原計畫以及儲存處理操作手冊，因此讀者可以看見，左邊的三項WP，都可以條列在右邊的一份建構管理計畫書中。

額外說明 -- 識別建構項目同BP1所提到，建立基準，是針對專案中的"重要"的建構項目。因此，何為重要？
我們要結合BP1額外說明的第(2)點，即建構項目的條件(管控方法)在專案中，常見的工作產出大致上可以分成三種：
1) 專案相關(Project Related)：
在管理流程或支援流程所產出的文件，這些文件可以指出在該專案進行時，主要的控管方法及計畫，例如: 專案管理計畫書中，可以清楚的了解專案的專案目標、人員職掌、里程碑、時程、等；在建構管理計畫書中，可以清楚的了解專案的建構管理策略，包含建構管理資料結構、基準時機、等。2) 產品相關(Product Related)：
在V-model過程中，所產出的重要文件，該文件將影響到下一個流程的運作，例如：客戶需求書、業界標準、業界規範、系統需求規格書、系統架構設計、軟體需求規格書、軟體架構設計、軟體細部設計，等。3) 流程相關(Process Related)：
該文件為專案所參照的主要標準流程，換言之，專案該如何進行與安排，將參照這些流程文件。在上述的三種工作產出中，我們將針對會被引用來做為執行的文件，進行基準控管。例如：專案計畫書，專案的所有人員將依據專案計畫書的內容來執行所有大小的工作，其他的計畫書也將按造專案計畫書的內容來編寫。
例如：系統需求規格書，系統架構設計將依造系統需求規格書來進行細部的設計。
例如：專案管理程序書，專案計畫書將根據程序書的規範來進行撰寫。那麼，什麼是比較不是那麼重要的內容呢？例如：專案週會紀錄，該紀錄只是週會的內容總結。
例如：專案時程表，該時程表經常變動，時程表主要是依據專案計畫書來進行安排，並且專案經理也會將專案的進度反應在時程表上。
例如：系統需求規格書溝通紀錄，該紀錄只是做為有溝通的證明。
例如：流程回饋單，該單據只是專案成員針對程序書是否合宜的意見回饋。簡單的針對上述的案例，分類建構項目，那麼可以得到：
- 針對計劃書、規格書、設計圖、程序書：這些將會影響到專案的計畫與執行，因此這些建構項目將被基準控管。
- 針對時程表、程式、業界標準：這些文件是次要產出、或是經常變動，因此這些建構項目將透過版本來控管。
- 針對會議記錄、審查紀錄、溝通紀錄、意見回饋：這些紀錄只是專案進行的紀錄產出，因此指透過儲存來控管。

—

SUP.8.BP3: Establish a configuration management system.
SUP.8.BP3: 建立一個建構管理系統
[Outcome 1,2,3,4,6,7]

Establish a configuration management system according to the configuration management strategy.

根據建構管理策略，建立一個建構管理系統。

—

SUP.8.BP4: Establish branch management.
SUP.8.BP4: 建立分支管理
[Outcome 1,3,4,6,7]

Establish branch management according to the configuration management strategy where applicable for parallel developments that use the same base.

根據建構管理策略，建立分支管理(適用於基於同基礎的平行開發)。

額外說明 -- 分支(與合併)管理 Branch and Merge Management專案中的文件較不適用分支與合併管理，通常是軟體開發的程式碼管理較適用此管理機制。分支與合併，通常也都會搭配工具來實現。常見的管理工具，包含Git或SVN，讀者可以再查找這類型工具如何實現分支與合併管理。以下為讀者推薦的學習資源：
30 天精通 Git 版本控管 - Will 保哥
講解 Subversion 分支與合併：以 TortoiseSVN 為例 - Will 保哥

—

SUP.8.BP5: Control modifications and releases.
SUP.8.BP5: 控制變更與發佈
[Outcome 3,4,5]

Establish mechanisms for control of the configuration items according to the configuration management strategy, and control modifications and releases using these mechanisms.

根據建構管理策略，建立控制建構項目的機制，並根據這些機致控制修改和發佈。

額外說明 -- 建構管理的變動 與 專案的變更過去在CMMI中，建構管理包含了專案的變更，但是ASPICE將這兩者切分的更細，因此可以剪單的理解，建構項目的變動將會在SUP.8，而專案的變更管理將在SUP.10。如下圖所示，為專案變更的管理流程圖。其中，綠色的部分為專案變更中的角色，而藍色的部分則為變更管理的步驟，橘色的部分為建構管理的變動步驟。一般來說，專案的變更，勢必會影響到專案的建構項目，尤其是已經被基準的建構項目，因此可以說建構管理只是變更管理裡面的其中一小塊。

額外說明 -- 變更管理應該注意什麼？過去，根據CMMI所定義的建構管理要求，當收到變更請求時，應當要有人全程監控變更的狀態，這個重責大任，過去落在建構管理工程師的頭上。然而，因為ASPICE標準將變更的層級拉到專案的層級，因此變更的主要監管與控制將落在技術部門主管，或是專案經理的頭上。雖然如此，建構管理工程師仍然需要針對建構項目進行管控。這邊提到的管控，即是BP條文說所謂的變動管理。一般來說，一個被基準的建構項目，當需要變動時，必須要有所憑據；請參考上圖，因此變更執行者，必須憑藉著被核准的變更向建構管理工程師提出建構項目的變動申請，這邊就是所謂的「簽出」，當建構項目被修改完畢後，則透握「簽入」完成入庫。由於建構管理工程師，必須要管控所有建構項目的狀態，因此也必須定期匯報所有被簽出的建構項目的狀態，藉此向專案負責人反應目前所有產出的狀況。--
簽出與簽入，都是需要有條件的。同上所述，簽出必須要有變更控制小組(CCB)的同意，而簽入則必須是該建構項目通過審查(驗證)。

—

SUP.8.BP6: Establish baselines.
SUP.8.BP6: 建立基準
[Outcome 2]

Establish baselines for internal purposes and for external delivery according to the configuration management strategy.

根據建構管理策略，針對內部目的和外部交付建立基準。

額外說明 -- 翻譯名詞「基準」Baseline在業界有兩種常用的名詞，一個是基準，另外一個是基線。筆者這邊是將Baseline翻譯成基準。

NOTE 4: For baseline issues refer also to the product release process SPL.2.
備註4: 關於基準的議題，也請參照產品發布流程(SPL.2)

額外說明 -- 內部目的 與 外部交付這邊所謂的內部目的，一般泛指需求基準、架構基準、開發基準、測是基準等。而外部交付，則是根據不同的產品發佈而定，例如：α版、β版、正試發行版、等，因此外部交付通常需要參照SPL.2，即產品發佈流程。

—

SUP.8.BP7: Report configuration status.
SUP.8.BP7: 報告建構狀態
[Outcome 5]

Record and report status of configuration items to support project management and other relevant processes.

紀錄和報告建構項目的狀態，以支持專案管理和其他相關流程。

額外說明 -- 建構狀態報告 CSA Report這邊提到的CSA Report全名是Configuration Status Accounting Report，通常該報告會在週會的時候匯報給專案經理，內容一般包含：1) 建構項目的狀態
2) 建構項目變動的狀態
3) 建構管理稽核的結果(如果有執行)

NOTE 5: Regular reporting of the configuration status (e.g. how many configuration items are currently under work, checked in, tested, released, etc.) supports project management activities and dedicated project phases like software integration.
備註5: 定期報告建構狀態(例如: 目前有多少建構項目正在開發中、已簽入、已測試、已發布、…等)以支持專案管理活動和特定的專案階段，例如:軟體整合。

額外說明 -- 專案的三個觀點(進度、產出、品管)一般來說，專案管理存在三個觀點來確認專案的執行狀況。
1) 進度觀點: 
通常是專案經理負責，從專案時程以及當前的問題與變更狀態來衡量專案的開發進度跟狀態。2) 產出觀點: 
通常是建構管理工程師負責，從建構項目的完整性來提供專案經理相關的資訊，協助判定目前的專案執行狀態。(例如：當一個流程活動完成時，從進度的觀點來看，項目已經完成，但是仍然需要從產出的觀點來看，該流程的文件是否有正確的產出)3) 品管觀點: 
上述兩個觀點，都是第一人稱視角，也就是說都是由專案內部人員來說明專案的當前狀態，因此，品管觀點扮演著第二人稱視角，透過稽核的方式來協助專案團隊了解當前的執行狀況與品質。

—

SUP.8.BP8: Verify the information about configured items.
SUP.8.BP8: 驗證關於建構項目的資訊
[Outcome 6]

Verify that the information about configured items, and their baselines is complete and ensure the consistency of baselines.

驗證有關已配置項目及其基轉的資訊完整性，並確保基準的一致性。

NOTE 6: A typical implementation is performing baseline and configuration management audits.
備註6: 典型實現的方法是執行基準和建構管理審核。

額外說明 -- 建構管理驗證方法常見的方法，可以粗分成以下三種時機：
1) 每週的確認
2) 每次基準時的確認
3) 發佈時的確認每週及每次基準時的確認，一般會透過資料庫稽核(Repositories Audit)，這是由建構管理工程師自行檢查的方法，一般常做的檢查是檢查團隊成員是否有按照建構管理規則放置跟管理專案中的所有建構項目。另外一種是每次發佈的時後，需要進行確認，這種我們會稱之為建構管理稽核(Configuration Management Audit)，通常又可以細分成兩種，分別是實體建構稽核(Physical Configuration Audit, 簡稱PCA)及功能建構稽核(Functional Configuration Audit, 簡稱FCA)。--
*這裡的發佈指的不只是外部發佈，也包含內部發佈。
*建構管理稽核，有時又被稱之為發佈稽核(Release Audit)

—

SUP.8.BP9: Manage the storage of configuration items and baselines.
SUP.8.BP9: 管理建構項目及基準的儲存
[Outcome 4,5,6,7]

Ensure the integrity and availability of configuration items and baselines through appropriate scheduling and resourcing of storage, archiving (long term storage) and backup of the used CM systems.

透過適當地計畫將正使用的CM系統進行資源儲存、歸檔(長期存檔)及備份，以確保建構項目的完整性和可用性。

NOTE 7: Backup, storage and archiving may need to extend beyond the guaranteed lifetime of available storage media. Relevant configuration items affected may include those referenced in note 2 and note 3. Availability may be specified by contract requirements.
備註7: 備份、儲存、歸檔可能需要超出可用儲存媒介的保證壽命。被影響的相關建構項目可能包含備註2(分支的建構項目)和備註3(專案中所需要交付地建構項目)的內容。可用性可由合約定義。

額外說明 -- 備份與復原策略值得一提的是，這個條文雖然有提到備份，但是也提到需要確保備份後資料的可用性，因此在規劃備份策略時，也要記得規劃一份資料還原策略。如果有導入ISO 27001或公司存在MIS部門且有備份還原政策
那麼建議將專案所使用到的工具、資料庫、等納入公司的備份還原政策，備份與還原的計畫可以透過年度計畫的方式來呈現。

工作產出(Output Work product)

06–02 處理及儲存指南[Outcome 3,4,5,7]
08-04 建構管理計畫 [Outcome 1,2,7]
08–14 復原計畫 [Outcome 1,7]
13–08 基準 [Outcome 2,3,4,5,6]
13–10 建構管理紀錄 [Outcome 2,5,7]
14–01 變更歷史 [Outcome 3]
16–03 建構管理系統 [Outcome 1,3,4]

* ASPICE網站
* ASPICE 3.1標準

感謝閱讀本文章！

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

email: linchewing@gmail.com