(※ Configuration一詞，在CNS國家標準用語中，譯為 "組態"。)

在軟體專案中，買方為了要驗證，賣方已經完全依照合約需求及規格，在軟體組態項目上，已提供了買方所期望的效能能力，並證明，文件是已經交付的，組態項目的精確代表物，而買方所購買的是，符合買方所核准詳細規格的軟體組態項目，因此，需要實施軟體組態稽核(configuration audits)，包含功能組態稽核(FCA)與物理組態稽核(PCA)。而專案中於何時及如何實施組態稽核，以及組態稽核應有何種產出，乃是組態管理(configuration management)的重大課題。

在CMMI的CM過程領域中，對於專案組態稽核活動並沒有給出實務的作法與指導，因此，在國內，即使已經通過CMMI ML2或更高等級評鑑的組織，若非將此項工作忽略，即是誤將組態稽核交由品保人員來實施，成為品質保證工作的一環，更無法達到組態管理所要求的組態項目(CI)的完整性(integrity)與一致性(consistency)。

專案中的軟體組態稽核，至少有10項稽核主題領域：
1.驗證程序與結果，滿足規格需求，並被接受。
2.效能規格是完整的，且足以定義該(等)項目。
3.詳細規格是完整的，且足以定義該CI。
4.軟體表列是完整的，且準確地反映可交付軟體媒體上所含數位資訊。
5.驗收測試程序及結果滿足規格需求，並被接受。
6.VDD是完整的，且準確地反映軟體營運與支援所需的文件
7.軟體媒體符合合約需求，且可依所欲目的使用
8.手冊是完整的，且準確地符合軟體的最新版本。
9.品項檢視/接收文件充分定義硬體/軟體。
10.合約商的工程釋出系統與變更控制程序，對於工程變更的處理與正式釋出是充分的。

在本課程中，將說明與組態稽核(configuration audits)有關的概念、組態稽核規劃與執行、各組態稽核主題項目如何查核、以及組態稽核應有的結果與產出。

CM概念與FCA/PCA的實務作法：有關組態稽核實施的實務部分從22:20之後開始。

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

標準不標準!!!

CNS 14238:1998 品質管理 - 形態管理指導綱要 idt ISO 10007:1995, Quality Management - Guidelines for Configuration Management

Configuration: 型態、形態、構型、組態、構形、.....

為何組態稽核不能交由品保人員來實施?品保在組織本來就是兼顧老板與顧客角色的代表，相對於研發或編碼人員，是獨立的第二方，不知誤在那裡?為何會影響到Configuration Management中Configuration Items的完整性與一致性?

Configuration Management是兼顧形式與內容的物管，由專案管理負責Configuration Management會太著重於形式，Configuration = Characteristics，Quality Control and Quality Management不就是以物(products)的特性(characteristics)或事(processes)的參數(parameters)為工作對象嗎?為何還要創造其他負責的人?

1. ISO 10007 (CNS 14238)在國際標準化組織是在TC176/SC2中所制訂。

2. 與系統工程、軟體工程有關的process、定義等的標準，屬於JTC1，其中比較關心的像是ISO/IEC 12207(軟體生命週期過程標準)及ISO/IEC 15288(系統生命週期過程標準)及ISO/IEC 24765 (系統工程與軟體工程字彙)，這些是由JTC1/SC7(聯合技術委員會1/子委會員7)所制訂。在此體系中，configuration及configuration management有關的意義與作法均有其定義，這類用語的定義其承襲美軍軍規、IEEE S2SC。看看ISO/IEC 24765再對照美軍軍規或軍方手冊(含MIL-STD 973、MIL-HDBK-61及MIL-STD 1521B)、IEEE 1042、IEEE 828等標準，即可知道其間的關聯性。而MIL-STD 973與MIL-HDBK 61等其歷史，均早於ISO 10007，且較ISO 10007的內容更為深入、規定更詳細。

3. ISO 10007屬於品質系統ISO 9000系列文件，目的在建立組織的品質管理系統，並使之有效運行。ISO 10007要處理的雖然不只是文件，同時，MIL-HDBK-61後期的版本，亦提到對於ISO 10007的符合，但是此一規定係為有助於產品品質的管理。

4. configuration 為何不能交給品保人員來實施，這個問題在於現在國內對於所謂的品保人員有所侷限，就是在管ISO 9000品質管理制度的那些人，品質小組、內稽的人員。但基本上，所謂的品質保證人員，應該是廣義的，我們在對於角色的定義時，其實是以其工作而賦予其名。也就是，執行品質保證工作的人員，才稱之為品保人員。因此，執行品質保證的人，除了根據原則--不能稽核自己的工作，其實產品的開發，很多都該是由開發小組的人員來實施的(這些人參與品保工作時，也就是品保人員)，像是需求分析文件，會由分析師、設計師、測試人員等等一起來審查，這種工作中，品質系統的品質保證人員會參與，但是他們看的是該項"審查活動是不是依照組織或專案的標準來實施"，對於真正產品的品質保證活動，其實是分析師、設計師、測試人員來實施的(對產品的真正品保人員)。之所以如此，因為品質保證人員對於技術性的東西是不了解的，當然，組織裡有很多活動，外部稽核的時候，會有外部專家來提供意見，內部稽核時，稽核小組是由各功能部門納編人員來實施的，如果不是如此，那麼這個品質稽核人員可能就神通廣大了，什麼都懂，甚至於組織裡所有部門的工作都要有經驗才行。不然叫這些人來稽核或做品質保證，那是"看熱鬧"而已，無法"看出門道"。對於configuration的FCA、PCA應該有一群人叫做Configuration Auditor(從工作的角度來看，賦予其名，而誰是組態稽核員，甲乙雙方的專案管理代表、需求提出者的代表、使用者代表、開發小組的代表等等)。

5. 品質保證是個概念，實際的執行，其使用技術包括驗證、確認、審查及稽核(可參閱ISO/IEC 12207:1995(E)的附錄)。所以正常來說，除了因工作的當下，賦予其名，而名之為"品質保證者"(同樣見12207:1995)，不該有一種人叫做 "品保人員"或"品保工程師"，有的話是很奇怪的事情，但是不明究理的人或組織，總以為，在組織或專案裡設一個品保工程師的職缺，這樣產品的品質就有保障。但是，品質稽核看的是對於計畫與標準(包含過程標準)的符合性，而驗證、確認、審查等所看的範圍就會包括需求、技術、及產品實現有關的細節了。

6. 品質人人有責。專案或組織裡有品質保證工程師的編制，並不會讓產品品質獲得保證，真正要讓人對品質有信心，是需要組織裡的每個人一起貢獻心力的。品質保證工程師，除非自己也參與開發、驗證、確認、審查、測試的工作，否則永遠只能看到文件是不是合乎要求的格式、有沒有錯別字、圖示是不是專案或組織所要求的，看不到需求有沒有被展成設計，有沒有將技術風險納入考量，change reguest裡所有該做的事情(不只是把表格中該填的東西填滿而已)是不是付諸實行，納入需求、設計，並且實現於產品之中了。

7. "品保在組織本來就是兼顧老板與顧客角色的代表，相對於研發或編碼人員，是獨立的第二方"，國內實務上是否如此？每個組織不同，更多的組織其品保所負責的主要是品質管理系統那一塊而已。而從ISO 9000系列中，亦未有明確的說"品保代表老板與顧客"，這個說法可能只是一些ISO 9000顧問自己的解讀而已，至少個人接觸ISO 9000系統多年時間，沒有聽過這個說法。而顧客，從品質的觀念來說，指的是產品/服務的接收者。如果花錢的客戶有10項需求，但是設計者只提出了9項需求的設計，誰能說這個有問題？品質稽核/品質保證工程師會看出來嗎？也許花錢的客戶在某次的會議中將其中的一項去掉了，也或許是提出了CR，將其中一項去掉了，也或許設計者在系統/軟體架構設計階段遺漏了一項，或許根本沒有漏，只是軟體架構設計的時候，依技術做了整合、合併所以看起來好像遺漏了....這些，品質稽核/品質保證工程師看得出來嗎？要他們看得出來，可能需要給很多的教育訓練及工作經驗吧。

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