請問何謂Functional Configuration Audit (FCA) 與Physical Configuration Audit (PCA)?何時執行?如何執行?由誰執行?其目的為何?

在回答問題之前，首先先來看看一些相關標準、技術報告(CMMI-Dev)及指引上對於FCA及PCA的定義：
(1) MIL-Std 973 組態管理
Functional Configuration Audit (FCA). 在驗收之前對組態項目之功能特性所實施的正式檢驗，以查證該組態項目已達成其功能(functional)與分配(allocated)組態文件中所規定的需求。
Physical Configuration Audit (PCA). 依據組態項目之技術文件對完成(as-built)之組態項目實施的正式檢驗，以建立或查證組態項目的產品基準。

(2) MIL-HDBK-61 組態管理指引
Functional Configuration Audit (FCA)-功能組態稽核用以查證組態項目的實際效能符合描述於其效能規格中所述的需求，以及查證組態項目已符合這些需求。對於系統，FCA用以查證系統實際的效能符合系統效能規格中所描述的需求。
Physical Configuration Audit (PCA)-用以檢驗代表產品組態之組態項目的實際組態，以查證相關的設計文件符合可交付之組態項目之設計。其亦用以確認契約商用以產出該組態項目的多項支援性過程。PCA亦用以查證，於FCA完成後，重新設計之組態項目之元件，亦滿足該組態項目之效能規格的需求。

(3) MIL-Std 1521B 系統、設備、與電腦軟體之技術審查與稽核標準
Functional Configuration Audit (FCA). - 正式的稽核，以確認(validate)組態項目之發展已滿意地完成；組態項目已達成功能與分配組態識別(functional or allocated configuration identification)中所規定之效能與功能特性。此外，完成的運作與支援性文件應予以審查。

Physical Configuration Audit (PCA). - 指定之組態項目的技術性檢驗，以查證已完成的組態項目與定義該組態項目之技術文件相符。

(4) EIA -836 組態管理資料交換與互運性
採用IEEE Std 610.12的定義

(5) IEEE Std 610.12
functional configuration audit - 就查證下列事項所舉行的稽核：組態項目的發展已完全令人滿意地完成；組態項目已達成功能或分配之組態識別中所規定的效能與功能特性；其運作使用與支援之文件已經完成且令人滿意。
physical configuration audit - 為查證所完成的組態項目符合定義該組態項目之技術文件所舉行的稽核。

(6) IEEE STD 828 - 軟體組態管理計畫書標準。使用之相關定義沿襲610.12
(7) IEEE STD 1042 - 軟體組態管理指引。使用之相關定義沿襲610.12

(8) CMMI-Dev V1.2
Configuration audit - 為查證組成基準之組態項目符合規定之標準或需求所舉行的稽核。
functional configuration audit - 就查證下列事項所舉行的稽核：組態項目的發展已完全令人滿意地完成；組態項目已達成功能或分配之組態識別中所規定的效能與功能特性；其運作使用與支援之文件已經完成且令人滿意。(同IEEE Std 610.12)
physical configuration audit - 為查證所完成的組態項目符合定義與描述該組態項目之技術文件所舉行的稽核。(同IEEE Std 610.12)

(9) ISO/IEC 12207/15288
(9.1) ISO/IEC 12207:2008 系統與軟體工程--軟體生命週期過程
Audit - 由獲得授權之人員，對軟體產品及過程實施的獨立評鑑，以評鑑對於需求的遵循性。
Evaluation - 個體滿足其規定準則之程度的系統化判斷。
functional configuration audit - 未定義。參照ISO 10007
physical configuration audit - 未定義。 參照ISO 10007

(9.2) ISO/IEC 15288:2008 系統與軟體工程--系統生命週期過程
Audit - 為取得稽核證據並對之客觀評估，以判斷稽核準則被滿足程度的系統化、獨立且文件化的過程。[改寫自ISO 9000:2005]
functional configuration audit - 未定義。參照ISO 10007
physical configuration audit - 未定義。參照ISO 10007

(10) ISO 10007 (CNS 14238) 品質管理系統--組態管理指導綱要
組態稽核(CA)須依照文件化的程序予以執行，以決定產品是否符合其要求與產品組態資訊。
功能組態稽核(FCA)：此為正式檢查以查證組態項目業已達成產品組態資訊所規定的功能與性能的特性。
實體組態稽核(PCA)：此為正式檢查以查證組態項目業已達成產品組態資訊所規定的實體特徵。
在正式接受組態項目前，可要求執行組態稽核，此舉並無意取代查證、審查、測試或檢驗等其他形式，但將會受到這些活動結果的影響。

由上面一些文件的定義，我們可以知道，FCA可以總結為：將組態項目或可交付的產品，與其功能或分配文件相比對，以了解功能或分配文件中所要求的組態項目或產品的需求是不是都已經被實現在產品中了。而PCA則是：將組態項目或可交付的產品，與其設計文件相比對，以了解其技術要求與工程方法是否依設計文件之描述，施於組態項目或可交付的產品上了。在工作的進行當中，相關的評估、審查、測試的結果，都是實施FCA與PCA的重要參考。

至於執行的時機，可以是在產品交付給客戶辦理驗收之前，或者是交付生產之前(硬體產品)，至少實施一次，但是亦可在各項組態項目完成之時。有些比較複雜的系統，其PCA可以採取漸增方式實施。

至於如何實施，或者實施的程序、方法論為何，其相關規劃的工作屬於契約甲乙雙方的職責，是具有彈性的。但是不論如何，應該要能達到其目標/目的，也就是「判別出組態項目(產品)與定義描述該組態項目的文件是符合的」。至於由誰執行，應採取Joint方式實施，亦即由甲乙雙方共同實施(同一個分組中，甲乙雙方均有人員)，若有丙方參與更佳。相關執行細節可以參考MIL-HDBK-61及MIL-STD-1521B(兩項文件雖已被美國軍方停用，但是仍然具有相當大的參考價值)。

----------------
引文:

(補充)

FCA/PCA這題應比較適合放在Configuration Management(CM)下面，為CM的四大工作領域之一

FCA/PCA最早出現在1521，屬於"技術審查與稽核"

480-483(CM標準)也把FCA/PCA納入，造成二者間之"衝突"

2167/2167A當時(引用1521B及480-483)並沒有將這個議題處理好，模糊帶過

到了973，才終於將FCA/PCA定位在CM，將"構型稽核"與"技術審查"切割

498開始，便承接了上述"定位"結果而"定調"

在ISO/IEC 12207中，其實並沒有FCA/PCA，但有一個活動項目-configuration evaluation，在其中的要求是：functional completeness of the software items against their requirements and the physical completeness of the software items (whether their design and code reflect an up-to-date technical description)。還是存在著FCA與PCA的影子。

從管理的角度而言，是否一定要非用FCA/PCA這種用語不可，個人以為並不重要，只要達到目標即可。這也是目前軟體工程過程國際標準的一種趨勢，能夠達到目的即可，做法與用詞是可以調整或自行定義的。在ISO/IEC 12207當中，我們是看不到文件的名稱、看不到軍規的一些慣用語，而將重點置於工程過程管理的要求上。

----------------
引文:

是否有CMMI-Level x公司能分享曾執行過FCA/PCA之經驗?

NASA的FCA Checklist與PCA Checklist下載：
http://software.gsfc.nasa.gov/AssetsApproved/PA3.1.1.3.doc
http://software.gsfc.nasa.gov/AssetsApproved/PA3.1.1.4.doc
上面的資料應該夠您用了
(按：此處用的是498 之Approach)

是否有CMMI-Level x公司能分享曾執行過FCA/PCA之實務經驗?
在PCA中所提及的First Article應如何定義?

請問，"PCA的First Article"是什麼？

First Article是首產物，就是第一件產品的意思

事實上，在還沒有軟體(工程)及CMM/CMMI的年代，PCA/FCA已行之多年矣....不是啥新東西....

其實PCA與FCA和CMMI無關，原本是在美國官方/軍方採用，後來歐洲人及台灣的軍方也(效法美軍)跟著用，台灣一般民間應該很少遇到(除非有做軍方案子且該專案恰有要求才會碰到)...

PCA/FCA原始用法是對硬體/系統(工程)之稽核，並非對軟體，其在硬體/系統專案之運用上均極為成熟

軟體(工程)因屬落後產業，包括PCA/FCA在內等之諸多活動都是向硬體/系統(工程)方面學習，有樣學樣

FCA稽核功能，對軟體言，實務上最主要是「稽核」(軟體FQT的)測試報告(按：就是2167A/498上面說的STR)

PCA稽核實體，也就是"驗明正身"的意思，對軟體言，其實務主要在「稽核」(所建置的)程式碼及(或)資料庫。

台灣軍方也有通過CMMI L3/L5者，其實例因屬軍機，故應無法"分享"。

最近聽說某CMMI ML3單位包的政府部門專案，其FCA(functional configuration audit)與PCA(physical configuration audit)是交給QA(qaulity audit)做的。其理由可能是因為都是稽核(audit或中文實應稱「審計」，QA中國譯為「質量審計」，台灣譯為「品質稽核」，中華民國審計部的英文名稱為：Ministry of Audit, R.O.C (Taiwan))。也不知道是那位顧問教的，執行CMMI評鑑的主任稽核員好像也沒有看出這是有問題，因為得到的PCA與FCA的品質會不一樣。當然也這也意味，相關人員對於何謂稽核、何謂品質稽核、何謂FCA、何謂PCA，各個目的為何，該怎麼做，要達到什麼結果，最終要做的決策是什麼可能都不是很清楚，應該好好讀讀各項標準(國際標準、美軍軍規、IEEE標準、EIA標準)中，有關configuration management的部分，甚至於CMMI裡相關部分要好好搞清楚。最簡單的，如果QA與FCA、PCA是一樣的，何必那麼費工夫要區分出來QA、FCA與PCA，全部都叫QA就好了；而如果只要是叫audit，auditor就什麼都可以做的話，那找審計部裡的官員來做好了，這個應該最有公信力。

----------------
引文: