前言

相信每個從事汽車電子開發的人都會有這樣的心路歷程：1.剛畢業時，懵懵懂懂的進入公司，跟著公司的培訓走，瞭解自己崗位的內容，以及與其他崗位的互動，還要熟悉V模型開發流程；2.工作幾年後，睜開眼睛看外部的世界，例如跟從事IT行業的同學們聊聊，跟轉行做醫療器械的同學們扯扯，突然會想一件事情，為什麼汽車電子的開發會是這樣一種形態呢？都涉及到系統和軟體的開發，但是組織形式和開發形式卻又如此的不一樣？是什麼東西在指導並搭建了這樣一種特定的開發組織形式呢（即開發流程）？

具體再提幾個深入一點的問題：

• 為什麼汽車電子行業的開發要有系統、軟體、硬體、結構（機械）、匹配、整合、測試、驗證、確認、製造、質量管理、工程專案管理、產線專案管理、產品管理、風險管理等複雜的開發人員設定？
• 為什麼在汽車電子相關的幾個供應商和主機廠跳來跳去，發現公司的專案組織形式和部門組織形式都大差不差，都長成某種特定的樣子呢？
• 為什麼汽車行業那麼多搞開發的不會寫程式碼？不會寫程式碼也能特麼叫開發人員？？
• 為什麼汽車電子開發要用V-model流程進行開發？

上述一切的答案就在於ISO15504 - Automotive Software Process Improvement and Capability dEtermination（Automotive SPICE，軟體流程改進和能力測定的汽車行業定製化版本）。這是一個由歐洲車企發起的車載軟體開發的流程標準，用於歐洲主機廠對供應商進行軟體流程能力評估。包括：奧迪、寶馬、賓士、菲亞特、福特、捷豹路虎、保時捷、大眾、沃爾沃等。

這個流程集合的意義在於，假如某個車企的軟體是按照這個流程開發出來的，就認為符合“車規”，軟體的功能安全等級能夠滿足車輛安全要求。

 

正文

A-SPICE 3.0 總覽：

 

%%%%%%%%%%%%%%%%% 分割線 %%%%%%%%%%%%%%%%%%%%

具體工程開發流程步驟（ENG）

現在知道汽車電子零部件供應商裡的系統工程師角色來源了吧？

看SYS.1/SYS.2/SYS.3/SYS.4/SYS.5的流程定義，需要這麼一個角色來cover對應著五個環節的任務。分別是：需求獲取、系統需求分析、系統架構設計、系統整合和整合測試、系統確認測試。

 

按照開發步驟詳細講講工程開發細節：

 

------------------------------------------------------------

需求獲取：從客戶獲取客戶需求，並確認需求被正確理解；

 

---------------------------------------------------------

系統需求分析：將已定義的客戶需求轉換為一組系統需求，用以指導系統設計；

過程成果：

a. 已經定義了系統需求；

b. 已經對系統需求進行了分類和分析以獲取正確性和可驗證性；

c. 已經分析了系統需求對執行環境的影響；

d. 已經定義了實現系統需求的優先順序；

e. 系統需求能夠根據需要更新；

f. 已經在利益相關者（客戶等）需求和系統需求之間建立了一致性和雙向可追溯性；

g. 利益相關者需求已經根據成本，進度和技術影響進行了評估；

h. 系統需求已經傳達給受影響的各方並且達成了一致。

輸出物包括以下幾種：

需求分析報告（RAR, Requirement Analysis Report）,比如診斷、CAN通訊、XCP、電源、KAM儲存機制等模組的RAR分析報告。

系統需求說明書（SYSRS, System Requirement Specification），裡面需要定義好功能需求和非功能需求。系統說明書的結構可是按照專案相關集分組，也可按照專案邏輯順序進行排序，也可根據專案相關標準進行分類，還可根據客戶要求來分類。

介面需求說明書（IRS，Interface Requirement Specification），定義各個系統模組之間的介面。例如：兩個產品之間、過程之間或者過程任務之間的關聯；雙方共同遵守的準則及格式；關鍵時間依賴性或前後順序；描述各個系統元件之間的物理介面，如匯流排介面（CAN、LIN）、收發器（型別、製造廠商）、附加介面（IEEE、ISO、USB等）、數字介面（PWM）和模擬介面等；識別軟體與軟體元件之間的介面，如程序間通訊機制、匯流排通訊機制等。

驗證標準（Validation Specification）。具體內容包括：1. 每條需求都可驗證或評估；2. 驗證準則定義了驗證需求時所遵循的定性及定量的準則；3. 驗證準則標明進行需求驗證時所遵循的已達成共識的約束條件。

審查記錄（RR，Review Record）：需提供評審的上下文資訊（內容、出席評審的人員列表、評審狀態）、覆蓋資訊（checklist、review標準、需求、標準符合性）、檢查發現（不一致性、改進建議）、記錄資訊（評審準備完成狀態、評審準備所花時間、評審所花時間、評審人員和角色的評審意見）、識別所需的糾正資訊（風險識別、偏差list、解決問題所要求的行動及任務、糾正措施的負責人、已識別問題的狀態及目標關閉日期）

跟蹤記錄（TR，Traceability Record）：跟蹤所有需求（客戶需求和內部需求）、識別生命週期中的產品&需求之間的對映關係、需求和工作產品之間的連線關係（例如：需求-設計-程式碼-測試-交付）、在生命週期各階段提供需求到相關工作產品之間的正向和反向對映

溝通記錄（Communication Record）：信件、傳真、電子郵件、語音記錄、電報；

變更控制記錄（Change Control Record）, 記錄變更請求，生成基線化產品（baseline product）。具體包括：採用控制機制來控制正式專案的基線化產品（baseline）、變更請求記錄（識別受變更影響的系統即文件、識別變更請求、識別變更的負責團隊、識別變更的狀態）、與相關客戶請求及內部變更請求建立連線關係、適當的批准、對重複的請求進行識別和分組

 

---------------------------------------------------------

系統架構設計：建立系統架構，確定哪些需求分配給哪些系統元素，並根據定義的標準評估所設計的系統架構。 具體的：

a. 提供所有系統的設計；

b. 描述系統元素之間的相互關係；

c. 描述系統元素與軟體之間的相互關係；

d. 詳細說明每個必需系統元素的設計，需要考慮到以下內容：記憶體和容量的需求、硬體介面需求、使用者介面需求、外部系統介面需求、效能需求、指令結構、安全及資料保護特性、系統引數設定、人工操作、可重用元件等

e. 系統元素與需求之間的對映關係

f. 描述系統元件執行模式（啟動、停止、睡眠模式、診斷模式等）

g. 描述在不同執行模式下各個系統元件之間依賴關係；

h. 描述系統和系統元件的動態行為。

過程可能產生的成果：

a. 已經定義了系統架構設計，並已經標識了系統元素；

b. 系統需求已經被分配給了系統元素；

c. 系統元素的每個介面已經定義；

d. 已經定義了系統的動態行為目標；

e. 在系統需求和系統架構設計之間已經建立了一致性和雙向可追溯性；

f. 系統架構設計已經傳達給受影響的各方並且達成了一致。

 

------------------------------------------------------------------

軟體需求分析Software Requirements Analysis：將系統需求的相關部分轉換為一組軟體需求

1. 指定軟體需求：使用系統需求、系統架構及以上兩者的變更需求來確定所需軟體的功能和特性。在軟體需求規範中指定功能性和非功能性軟體需求。只有在軟體開發中，系統需求和系統架構才會設計到一個給定的操作環境。
2. 結構化軟體需求：結構化可以按照專案相關的叢集分組，或者按照邏輯排序，或者按照相關標準進行分類，或者為干係人需求設定優先順序。
3. 分析軟體需求：分析指定的軟體需求包括他們的相互依賴關係、確保正確性、技術可行性、可驗證性和支援風險識別。分析成本影響，進度和技術的影響。
4. 分析對操作環境的影響：分析系統元素介面和操作環境對軟體需求的影響；
5. 開發驗證標準：為每個軟體需求開發驗證標準，以便於每條需求驗證可以定性和定量的度量。
6. 建立雙向可追溯性：建立系統需求和軟體需求之間的雙向可追溯性。建立系統架構和軟體需求之間的雙向可追溯性。
7. 確保一致性：確保系統需求和軟體需求之間的一致性。保證系統架構和軟體需求之間的一致性要求。
8. 溝通已確認的軟體需求：溝通已確認的軟體需求併為所有相關方更新這些軟體需求。

 

輸出物包括：

1. 溝通記錄；
2. 審查記錄；
3. 變更控制記錄；
4. 追溯性記錄；
5. 分析報告Analysis Record：分析的內容、分析人、所採用的分析準則（選擇的準則或採用的優先順序計劃、決策準則、質量準則）、記錄結果（決定或選擇的內容、選擇的原因、做出的假定、潛在風險）、正確性分析的方面（完整性、可理解性、可測試性、可驗證性、可行性、有效性、一致性、內容的充分性）
6. 介面需求規格說明書（IRS）：更新細化
7. 軟體需求說明書（Software Requirement Specification）：識別適用的標準、識別軟體架構考慮及約束條件、識別必需的軟體元素、識別軟體元素之間的關聯關係、考慮給出以下資訊（必需的軟體效能特性、必需的軟體介面、必需的安全特性、資料庫設計需求、必需的錯誤處理及屬性恢復機制、必需的資源消耗特性）
8. 驗證標準

 

--------------------------------------------------------

軟體架構設計Software Architectural Design：建立一個架構設計和確定哪些軟體需求分配給軟體的哪些元素，並根據定義的標準評估軟體架構設計。

過程成果：

1. 定義了軟體體系結構設計，確定了軟體的元素；
2. 軟體需求分配給軟體的元素；
3. 定義了每個軟體元素的介面；
4. 軟體元素的動態行為和資源消耗目標已定義；
5. 建立軟體需求和軟體架構設計之間的一致性和雙向可追溯性；
6. 軟體架構設計被所有受影響的各方達成一致並已溝通。

具體步驟：

1. 軟體架構設計：指定軟體要素和相關方面的功能和非功能軟體需求；軟體在適當的層級分解為元素，並在詳細設計中描述元件（所謂元件，指軟體架構設計的最底層的元素）；
2. 分配軟體需求：分配所有軟體需求到軟體架構設計元素；
3. 定義軟體元素介面：識別、開發和文件化軟體元素之間的介面；
4. 描述動態行為：參照系統動態行為，評估和文件化軟體元素間的時序和動態互動行為。（動態行為是由操作模式確定的，如啟動、關閉、正常模式、校準、診斷等等；程序和程序內部通訊、任務、執行緒、時間片、中斷等。另外，在評估動態行為時，目標平臺和潛在載荷應被考慮）；
5. 定義資源消耗目標：在軟體架構設計的適當層級，為相關元素定義並記錄所有軟體元件的資源消耗目標。（資源消耗通常被明確為資源，諸如記憶體ROM、RAM、外部/內部EEPROM或Flash資料，CPU負載等）
6. 評估可替代的軟體架構；
7. 雙向可追溯性（需求與架構之間）
8. 確保一致性
9. 溝通已確定的軟體架構設計

輸出物：

1. 軟體架構設計：包括內容有：

a. 軟體架構整體描述；

b. 包含任務結構的執行系統描述；

c. 確定任務與程序之間的通訊；

d. 識別必需的軟體元素；

e. 識別自主開發及供應方提供的程式碼；

f. 識別軟體元素之間的關聯及依賴關係；

g. 確定資料儲存及災備方案；

h. 描述不同模型系列或配置如何衍生出產品變體；

i. 描述軟體的動態行為（啟動、關閉、軟體升級、錯誤處理、恢復）；

j. 確定資料儲存位置及資料損壞的預防辦法；

k. 描述哪些資料是在什麼情況下是持續存在的；

l. 還要充分考慮以下內容（軟體必需的效能特性、軟體必需的介面、軟體必需的安全特性、資料庫設計需求）

 

2. 介面需求規格說明書

3. 跟蹤記錄

4. 審查需求

5. 溝通記錄

 

-----------------------------------------------------------

軟體詳細設計和單元實現Software Detailed Design and Unit Construction：步驟幾乎以以上步驟完全一致...

 

-------------------------------------------------

軟體單元驗證Software Unit Verification：軟體單元測試過程的目的是驗證軟體單元，證明軟體單元符合軟體詳細設計和非功能性軟體需求。

過程成果：

1. 指定了包括迴歸策略在內的軟體單元驗證策略；包括軟體單元發生變更時重新驗證的迴歸策略。驗證策略應定義如何證明軟體單元符合軟體詳細設計和非功能性需求。單元驗證的技術可能包括靜態/動態分析、程式碼審查、單元測試等。
2. 根據軟體單元驗證策略開發軟體單元驗證標準，該策略適用於證明軟體單元提供符合軟體詳細設計和非功能性軟體需求；單元驗證標準可能包括單元測試用例，單元測試資料，靜態驗證，覆蓋目標和編碼標準；單元測試規範可以實現諸如作為自動測試臺中的指令碼。
3. 根據軟體單元驗證策略和軟體單元驗證標準對軟體單元進行驗證，並記錄結果；其中，靜態驗證可能包括靜態分析、程式碼審查、針對編碼標準和指南的檢查以及其他技術。
4. 在軟體單元之間建立一致性和雙向可追溯性，驗證標準和驗證結果；
5. 彙總單元驗證結果，並傳達給所有相關方。

 

輸出物包括：

1. 測試規範說明書 Test Specification：包括測試設計規格書、測試用例規格書、測試過程規格書、識別迴歸測試的測試用例；對於系統整合測試，要識別必需的系統要素，例如硬體要素、接線要素、引數設定和資料庫等；識別系統元素整合必要的序列或排序
2. 測試計劃Test Plan：分級的測試計劃、測試策略（黑盒/白盒測試、系統邊界測試、迴歸測試策略等）；如有必要，編制綜合測試計劃
3. 驗證結果及測試報告Verification Result and Test Report：驗證checklist、通過的項、失敗的項、待驗證的項、發現的問題issue、風險分析、解決方案、結論、簽名確認。測試報告按照要求，形成測試日誌分級、形成異常報告、形成測試報告分級。
4. 分析報告Analysis Reprot
5. 三記錄（溝通記錄、審查記錄、跟蹤記錄）

 

------------------------------------

軟體整合和整合測試Software Integration and Integration Test：將軟體單元整合到更大的軟體專案中，直到形成與軟體架構設計一致的完整整合軟體，並確保軟體專案是經過測試的，可以證明包括軟體單元之間和軟體專案之間的介面在內的整合軟體專案符合軟體架構設計。

步驟：

1. 開發軟體整合策略
2. 開發包括迴歸測試策略在內的軟體整合測試策略
3. 制定軟體整合測試規範。軟體整合測試用例可能關注：軟體專案間的正確資料流、軟體專案間的資料流的及時性和時間依賴性、使用介面對所有軟體專案資料的正確解釋、軟體專案間的動態互動、符合介面的資源消耗目標
4. 整合軟體單元和軟體項
5. 選擇測試用例，要有足夠的覆蓋度
6. 執行軟體整合測試
7. 老三樣（雙向可追溯、確保一致性、總結和交流經驗）

輸出物：

1. 軟體項，兩大塊，一個是整合的軟體，一個是文件。整合的軟體可分為：原始碼、軟體元素、可執行程式碼、配置檔案；文件包括：描述和識別原始碼、描述和識別軟體元素、描述和識別配置檔案、描述和識別可執行程式碼、描述軟體生命週期狀態、描述歸檔和釋出標準、描述軟體單元編譯、描述軟體元件的構建
2. 整合的軟體：多個軟體元件的集合。這裡的軟體一般是針對某一特定ECU配置的一組可執行檔案以及有關的文件和資料。
3. 測試老三樣（說明書、計劃、報告）
4. 記錄老三樣（溝通、審查、追溯）
5. 構建列表Build list: 識別軟體應用系統的聚合、識別所需的系統元素（引數設定、巨集程式庫、基本資料、作業控制語言等）、識別軟體編譯時必需的順序序列、識別輸入輸出資源庫。

 

-----------------------------------

軟體確認測試Software Qualification Test：確保整合的軟體已經過了測試並滿足軟體需求。與上一步幾乎相同。

 

-----------------------------------

系統整合和整合測試System Integration and Integration Test：整合系統項以生成整合系統，符合系統架構設計並確保系統項被測試，用以證明整合的系統項與系統架構設計的一致性，包括系統項之間的介面。

1. 開發包含迴歸測試策略的系統整合測試策略；
2. 開發系統整合測試規格說明書，包含：根據系統整合測試策略的每一個系統項整合階段的測試用例。有四個需要注意的點：a. 介面描述系統元素和系統整合測試用例的輸入關係；b. 符合架構設計：指定的整合測試能夠適時證明，系統項間的介面滿足系統架構設計提供的規範。c. 系統整合測試用例應關注：系統項間正確的訊號流、系統項間訊號流的及時性和時序、使用一個介面訊號的所有系統項的正確解釋、系統之間的動態互動關係；d. 系統整合測試可能支援使用模擬環境（硬體在環模擬、車輛網路模擬、數字樣機）。
3. 整合系統項；按系統整合策略，整合系統項，形成整合系統。系統整合可以逐步執行整合系統項（例如，作為原型硬體的硬體元素、外圍裝置、感測器、執行器、結構和已整合的軟體），生產出與系統架構設計保持一致的整合的系統。
4. 選擇測試用例：從系統整合測試規範說明書中選擇測試用例。有足夠覆蓋率。
5. 執行系統整合測試
6. 老三樣（雙向可追溯、確保一致性、總結和交流經驗）

 

--------------------------------------------

系統確認測試System Qualification Test：確保整合的系統已經測試，為符合系統需求和系統準備交付提供依據。與上述步驟大同小異，略。

 

 

%%%%%%%%%%%%%%%%% 分割線 %%%%%%%%%%%%%%%%%%%%

具體支援流程步驟（SUP）

 

一、質量保證流程 Quality Assurance（SUP1）

目的：為工作產品和流程嚴格按照預定義的規定和計劃提供獨立的、客觀的保證，並解決和預防不符合性的情況。

1. 開發專案質量保證策略；主要是保證工作產品和質量保證在專案層面獨立、客觀且無利益衝突地執行。所謂獨立性，可能是財務或組織架構的獨立。質量保證可能協調並利用其它流程的成果，比如核查、驗證、聯合評審、審計與問題管理。流程質量保證包括流程評估和審計，問題分析，定期檢查的方法、工具、文件和流程定義的堅持，報告和經驗教訓，為未來的專案改善流程。工作產品質量保證包括評審、問題分析、報告和經驗教訓，來改善未來的工作產品。
2. 確保工作產品質量；相關工作產品的需求可能包括適當標準帶來的需求。被發現的不符合的工作產品會進入問題解決流程（SUP9），並被歸檔、分析、解決和追蹤以關閉問題並預防。
3. 保證流程活動的質量；按照質量保證策略和專案日程表執行流程活動質量保證，以確保活動契合既定目標並把結果歸檔。相關過程專案標可包括從適當標準帶來的目標；在流程定義或實施過程中發現的問題可進入流程改善流程（PIM3），以描述、記錄、分析、解決和追蹤，最終關閉問題並預防。
4. 總結和溝通質量保證活動和結果；根據質量保證策略，定期給相關責任人報告效能、偏差和質量保證活動的趨勢以獲取資訊和行動。
5. 確保不符合項的解決；應當就過程和產品的質量保證活動中發現的不一致和偏差進行分析、追蹤、糾正並預防的工作。
6. 實施質量問題升級機制；根據質量保證策略建立一個漸進式管理機制，以確保可以將問題升至合適的質量保證管理等級和其它利益攸關方來解決問題。

輸出物清單：

1. 質量計劃：a. 質量目標；b. 定義保證質量所需的活動任務; c. 參考相關工作產品; d. 質量評估/保證的方法； e. 參考法規要求、標準及客戶需求；f. 識別預期的質量標準；g. 為定義的生命週期和計劃的相關活動指定監控時間表及質量檢查點; h. 以達到預期質量為目標設立時間表；i. 實現目標的方法：需要執行的任務、任務負責人、需要執行的審計、資源承諾；j. 識別工作產品和過程任務的質量標準。k. 指定採取糾正措施前允許的門限/耐受度；l. 定義質量度量和基準資料；m. 定義質量記錄採集機制和採集時機；n. 指定質量報告對過低質量所影響過程的反饋機制; o. 由質量責任機構/部門的批准；p. 定義質量保證（QA）的獨立性；q. 確定升級機會和渠道; r. 定義客戶與供應商質量保證之間的協作。
2. 質量記錄；定義需要保羅的資訊；定義產生資訊的任務/活動/過程；定義資料收集日期；定義相關資料來源；識別相關質量準則；使用資訊識別相關的度量；識別建立記錄或記錄需要滿足的、需要遵循的任何需求。
3. 審查記錄：略
4. 問題記錄：識別問題報送人的姓名與相關聯絡細節；識別負責修復問題的組織/人員；包含問題描述；識別問題的分類（嚴重度、緊急度、關聯性等）；識別已報告問題的狀態；識別問題修復的目標釋出版本；識別問題的預期關閉日期；識別問題關閉準則；識別問題複驗活動。
5. 糾正措施記錄：識別初始問題；識別行動項的負責人；定義解決方案（為解決問題而採取的一系列行動）；識別問題發現日期及期望關閉日期；包含狀態指示器；標明後續的稽核活動。
6. 質量標準。定義對質量的期望。建立工作產品充分程度的準則（必需元素、預期的完整性、精確度）；識別構成已定義任務的完整性的內容；建立生命週期變遷準則，以及每個已定義過程/活動的准入準出條件；建立預期的效能屬性；建立產品可靠性屬性。

 

---------------------------------------

二、配置管理 Configuration Management（SUP8）

配置管理流程，是為了建立和維護所有流程或專案工作產品的完整性，並提供給相關干係人。

1. 開發配置管理策略，包括： 職責和資源、工具和儲存庫、對配置項及其命名規範的識別、許可權、配置項的歷史和基線（需要/可選的基線；命名規範；分支方法、合併以及建立基線；釋出和批准基線）。配置管理策略通常為了配合商務搞的不同版本的產品（Variants變種）配置管理。
2. 識別配置項；軟體開發的配置項通常是：配置管理計劃；需求文件、架構和設計文件；軟體開發環境；軟體開發計劃；供應商協議；質量保證計劃；軟體單元程式碼和文件；應用引數；測試用例和測試結果，評審記錄；編譯清單，整合報告；使用者手冊。硬體和結構也可以有配置項，例如硬體佈局、圖紙、電路板、物料清單等。
3. 建立分支管理策略。指定分支管理策略，適用於使用相同原始碼基線進行並行開發。分支管理策略列出了關於何種情況下允許分支，是否需要認證，分支如何合併，需要怎樣處理以確認所有變更在未央及其他變更和原生軟體的情況下相容地整合到一起。
4. 控制修改和釋出。根據配置管理策略建立配置項控制機制，並使用此機制控制修改和釋出。
5. 建立基線（baseline）。根據配置管理策略建立內部和外部交付基線。
6. 報告配置狀態。記錄並報告配置項狀態，以便於支援專案管理和其他相關流程。
7. 核實配置項資訊。例如評審。
8. 管理配置項和基線的儲存。

輸出物：

1. 配置項：包含模組、子系統、函式庫、測試用例、編譯器、資料、文件、物理介質和外部介面。除此之外，配置項還要有版本維護相關資訊。一般建立配置項表格時，需要包含配置項型別、相關配置管理庫/檔案/系統、責任人、置於配置管理控制下的日期、狀態資訊（例如：開發階段、已打基線、已釋出）、與下一層配置項的關聯關係、變更控制記錄的識別、變更歷史的識別
2. 處理和儲存指南：定義以下任務來實現產品的處理和儲存：提供原版程式碼副本及文件、災難恢復方案、登記關鍵安全性問題；提供描述來指導如何儲存產品：所需儲存環境、使用的保護媒介、所需包裝材料、儲存項、評估儲存產品；提供恢復指南
3. 配置管理計劃：定義或引用流程來控制配置項的變更；定義度量標準來確定配置管理活動的狀態；定義配置管理審計標準；由配置管理職能部門批准；確定配置庫工具或機制；含有控制項歷史及狀態的管理記錄及狀態報告；為配置管理庫指定位置及訪問機制；指定儲存、處理及交付機制。
4. 恢復計劃：識別恢復項，如執行恢復的規程和方法；恢復的時間表；關鍵的依賴關係；恢復所需的資源；備份維護列表；負責恢復的人員及分配的角色；所需特殊材料；所需工作產品；所需裝置資源；所需文件；備份的儲存位置；恢復的通知人聯絡方式；驗證步驟；恢復的成本估算。
5. 基線：標識一致且完整的一條或一組工作產品和工件的狀態；下一個過程階段的基礎；唯一的且不能更改的。
6. 配置管理記錄（工作產品或工作項的修改狀態；識別配置項；識別要執行的活動，例如備份、儲存、歸檔和交付配置項；維持產品一致性）
7. 變更歷史（變更描述、變更物件的版本資訊、變更日期、變更發起人資訊、變更控制記錄資訊）
8. 配置管理系統

 

-----------------------------------------------

三、解決問題管理

 

 

 

-----------------------------------------------

四、變更請求管理

 

 

 

------------------------------------------------

五、專案管理

 

 

 

------------------------------------------------------

六、供應商監控