各位好,
SQA(Software Quality Assurance) & CM (Configuration Management)這二者從字面上看起來是不同,不過有誰能夠簡單的描述SQA與CM的關係呢? 是否CM包含SQA的工作呢? 亦或者SQA與CM二者是完全獨立但存在其它串連的關係呢?

這個問題看起來好像是老師在考學生(不知道答對的有沒有獎品)，可是好像沒有學生應考喔。問題放在這兒吊大家的胃口也不太好，我就試著回答一下嘍，或者透過我的說法，可以讓大家腦力激盪一下。

基本上這兩項過程的目的是不同的，但不知道liangh的想法是什麼，因為談「關係」好像是並不太適合，因為，如果有關係的話，就可以考慮一下兩個過程是否可以合併。但是一般來說，一個設計良好的過程，它與其他過程的關聯性(耦合性)是要最低的，最好是建立在產品(工作產品)上。(看到這裡，已導入甚至於通過CMMI第三級以上評鑑的公司，EPG Leader可得好好檢查一下，自家的processes設計是否符合這個標準，否則工作上會多花很多工夫，耗費更多的成本)
所以第一個答案就那麼簡單，但我相信liangh對於這個答案應該不滿意，沒關係，我們看第二個問題好了。

第二個問題是，是否CM包含SQA的工作。答案是：對也不對。會有這個問題我想應該是，CM中有一項是構型(建構)稽核，構型稽核分為功能性構型稽核(functional configuraton audit, FCA)及物理性構型稽核(Physical configuration audit, PCA)(看的是產品的完整性)，而SQA裡常用品質稽核(quality audit)(注意SQA的"A"是Assurance，不是Audit)(其實看的是過程與產品的遵循狀況)，所以認為這個Audit與那兩個Audit是一樣的，當然，要把品質稽核放大到去容納那兩個稽核在觀念上也無不可，只是要了解，他們兩者所要求的產出是不一樣的喔，SQA的產出結果主要是品質稽核報告(針對過程與產品的compliance)，FCA/PCA之後會產出構型稽核報告(針對產品、需求、設計、技術等等的一致性與完整性integrity)，而通過構型稽核的產品(含文件)會被訂為產品基準(Product Baseline)(交付給客戶的產品的在Form, Fit, Function上的最終規格)。

當然在一個比較小時間短的專案裡，是可以用一組人馬把構型稽核及品質稽核同時做掉，然後各自提出所需要的產出物就可以了，這樣不會讓專案裡的人員疲於奔命。但如果要達到這樣子的彈性，各軟體組織的軟體過程設計就得要很小心謹慎了。做法最好是把「稽核」當成一項過程單獨從品質保證及CM裡分離出來，當SQA要執行稽核的時候，可以「叫用」此稽核過程裡的activities，而當CM要執行構型稽核時，也可以「叫用」此稽核過程裡的activities，然後依據SQA及CM的要求產出所需要的報告或紀錄。

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

謝謝Tyrone的解感,其實丟這個題目上來並不是要考大家,而是我最近的工作與V&V,SQA,CM都有關係,由於公司一直以來都有在做軟體品保的工作(例如軟體各階段有舉行各項Review會議),只是從前沒有V&V,SQA,CM這樣的角色定義或交由單獨的Team去運作. 當我看了一些V&V,SQA,CM等理論的書之後,我真的有些搞混了,從Tyrone上一篇的回覆我再翻閱書本後,我大約能夠了解CM 與SQA的不同,不過對於CM 講究的訂定Baseline及Checkpoint,我認為與V&V的觀念又很像,唯一不同的是CM有強調CCB的重要性.而V&V強調是廣義的測試.

所以下一個想請教的是,CM是否與V&V也有重覆的地方呢?

後半段有關於CM與V&V的部分另外成立主題。

我倒是沒有看到談CM的文獻裡用到Checkpoint這樣的字眼。顯然在一些流程(過程)的規劃上，發生了一些沒有切得很清楚的狀況。

在工程過程的設計上，屬於生命週期模型觀點的，就該規劃給生命週期模型，屬於生命週期過程角度的部分就歸於生命週期過程吧。

對於這些名詞的解讀建議最好從其目的與工程的意義來解讀，否則容易造成混淆，同時所設計出來的過程恐怕無法正確裁適，以整合到專案生命週期過程中，當然這也意味著無效的工作正在吞噬寶貴的專案資源--人力資源。

Baseline(基準)的定義是工程過程裡的某一個時間點上，經過審查及核准，並作為後續發展工作之準據的一份文件。如此而已。基準可能被修改，修改之後，經過審查及核准，成為新的基準，這件事情可以在任何時候發生。但是，常常發生這種狀況是不太好的，所以你要去設定一些限制，例如從變更產生的影響範圍，去思考需不需要立刻處理，或者可以累積一定的數量之後再去改變，或者用時間來律定。通常不考慮變更的狀況，基準會在生命週期的重要階段結束前，產出的文件經過審查會訂為後續階段工作的準據，這些基準常見的有功能基準、配置基準、產品基準等，當然這些是從系統工程所定義的，在軟體工程上，就沒有這麼多名詞，每個階段結束時經過核准，被確定下來，做為後一個階段工作依據的統稱為「基準」。

你所談到的checkpoint應該是指每個階段的結束點，在專案管理上這些一般會被訂為「里程碑(milestone)」，當然從品質的角度來說，這些時點又有一個名詞叫做「quality gate(品質閘門)」，但不論如何，"checkpoint"這個觀念應該是要從CM裡分離出來。

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

我喜歡用考駕照做為品質保證的對應~~
考駕照有一些要求,要會倒車入庫,路邊停車,直線加速, S型..等要求(What)..
我們必須要根據流程執行活動以滿足要求(How)..
如果不懂不會, 教練(輔導公司)會教..
上考場,監考官(稽核員或評鑑員)..會看是否符合要求...
監考官會將報告呈給監理處(認證機構),由監理處核給駕照...

所以,軟體品質保證是規劃並執行一系列活動, 以確保流程與產品符合要求, 而這系列活動包含了建構管理、確認、驗證、聯合審查..

朱慧德

SQA本身的意義在於透過一系列的方法(例如：Review、Audit)，去提供幕僚人員及管理者在於「產品與產出產品的過程是符合標準、要求及規範」的信心。

因此SQA與其他的支援性過程，例如Configuration Management、Verfication、Validation、Review、Audit、Problem Resolution、Change Management....等等不宜直接劃上等號或視為包含關係。從ISO的品質管理系統來說，要求所謂的「說、寫、做合一」，能不能通過ISO的稽核，主要是看你訂了多少規範與要求(這些要求與ISO 9001:2000的要求應該是要一致的，這是前提之一)，這些規範與要求你有沒有說到做到，做到了就可以通過認證。當然這也就是為什麼有人會垢病─按照標準還是做不好，其實並沒有這種問題，因為各公司只是按自己訂的制度在走而已，至於有沒有真的力行，那是另外一回事。

至於有了品質管理制度之後，卻沒有能把事情做好，這並不是出在品質管理系統或者SQA的問題(假設公司有按照自己訂出來的制度在執行)，所以就有一些過程標準，不論是從軟體角度出發的，或是從組織角度出發的標準：這些標準包括：
1. 過程角度：ISO/IEC 12207軟體生命週期過程、ISO/IEC 15288系統生命週期過程
2. 組織角度：CMMI以及CMMI前身框架(SW-CMM、SE-CMM、SA-CMM等等)
以上的這些標準，都包括了SQA及其他的軟體過程(含支援性過程)
組織可以將其中的過程要求，納到組織的品質管理系統當中，以改善及強化組織的軟體過程，進而達到所期望的品質，當然這些要被強化的過程當中是包括了SQA過程本身、CM的過程、驗證過程、確認過程、審查過程、稽核過程.....等等。因為這些過程都是屬於「品質」的一環。SQA屬於「品質」的一環，但並不代表有SQA就等於「品質」，因為若公司訂了SQA的過程，但是並沒有遵循此一規定的SQA過程來執行，那麼組織還是一樣「沒有品質」。SQA也不全然等於品質管理系統。

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

1.合約簽定時應明訂工程交付產出物(Products)，並在CDRL文件中載入Contract Products；要完成相關Products，便需要藉助相關Process完成，因此Products與Process架構出專案的主要活動，在專案的PMP (Project Management Plan)或SEMP (System Engineering Management Plan)也必須將此等Products與Process載入，這是說明 “what”的部份，同時在resource章節敘述由何項組織執行何項Products/Process，這是說明 “who”的部份；

2.專案由Risk Management以及Project Management角度進行規劃時，通常會將Process切割成Requirements、Design、Coding & Module Level Test、CSCI Integration Test等Phases，隨箸Phase的進行將完成Software Requirement Specification、Software Top Level Design Document、Software Detail Design Document、Source Coding、Software Transition Plan、Software User Manual、Version Description Document等Products，這是說明 “when”的部份；

3.要撰寫前述的Products或是CSCI documents，就需要參考Standards(例如Software Requirement Specification可參考IEEE-1233，一般而言美國政府已經不在RFP中訂定Standard(Valued Engineering除外)而由Tender在Proposal中自己敘述將參用的標準，因此參與專案的各個相關Process的Engineering Group須將可參用的Standards在PMP或SEMP中敘述（事實上應該在Management Proposal與Technical Proposal中已敘述），這是說明 “how”的部份；

4.文件撰寫完成後需要有審查與納管機制以達成建立baseline的動作，方可方便不同組織能夠依據此baseline document繼續往下一個phase展開後續的工程事項，因此要有Configuration Management的Baseline management程序(Procedures)，Procedures是屬於Process的 “Core part”，通常需要在Procedures中敘述entry criteria與exit criteria，每一家公司的組織架構不同，所以相同的Standard會產生不同的Procedures，Standard是可以是價購的，但Procedures無法由市面購得，Standard是可以放在Library，但Procedure要放在Organization Assets；

5.工程執行過程中會發生需求變更以及設計變更，因此需要有對於技術、時程、人力、預算、… 等變更影響的評估機制，以便在CCB中決定是否同意變更申請（包括軟體版本的配置），因此需要有CM的Change Management的制衡機制；

6.前述所言的軟體發展，如果由Phase的角度分析，Development的最後動作是要在CSCI完成Integration Testing後，確定可於相關的Products中Validate其滿足requirements或users needs，得以舉行Functional Configuration Audit (FCA) 並點收在合約書中所訂定的各項Products (可依據CDRL、CLINS點收)，FCA同時代表研發過程的結案，但如前述所言在發展過程中有可能發生Change requirement的情形，如果在申請需求變更時，專案已進入CSCI Integration Testing時，以標準程序(或Life Cycle)而言，此時的需求變更應被改納入New Block 或New Version而非revision，因此針對不同的CSCI Version會產生FCA1、FCA2、FCA3、…等，買方在量產時可基於成本、時程、架構、維修、市場、..等因素選定FCA2的購型並簽訂生產合約，同時在首批小量生產將CSCI+HWCI整合之實體購型(PCA)置於實體環境中測試其效能(FCA通常僅在Simulation Environment展示其符合requirement)，因此需要CM的FCA與PCA管制機制；FCA是依據軟體生命週期的Functional Baseline與Allocated Baseline之後所執行的Audit Procedures，PCA之後即完成CM的Product baseline；

7.以上所敘述的是工程團隊(Mechanization Team)，在完成products時必須配合CM所執行的Procedures，但是隨着軟體工程的執行，是否能順利的進入下一phase，必須藉助Verification的process以verify products是否可滿足Correct、Complete、Accurate、Consistent、Testable等目摽(Goals，參考IEEE-1012)，Verification可藉助Review、Analysis、Testing等方法(應該在technical proposal的VCRI中敘述，不同的方法會牽涉不同的成本)以確定前述之goals已於此階段完成，verification本身是屬於Project Management的Technical Discipline，其執行過程為(a)文件撰寫者完成初稿時交由Group或Organization的Senior Engineer進行初審(在CSCI Requirement範圍內)、(b)分會與介面相關的Group進行Peer Review、(c)呈送Project Office進行複審(跨多項CIs)，至於V&V的Validation是在Requirement Analysis phase時即由負責Validation的Testing group同時平行進行Test Evaluation Master Plan (TEMP)、Test Procedure、Test Case、以至Testing的執行，此Validation Process包括為了完成測試所必須發展或建置的Simulation Modeling Environment(有些測試是幾乎無法在實體環境中執行的)；

8.前述事項包括有工程發展Process、CM、V&V，每一項都有其應參用的標準(Standards)與程序Procedures，專案的Products與Process是否已依據Standard與Procedures執行，就必須由Quality Assurance (QA)進行Assurance的動作，但QA並無能力去進行確定Correct、Complete、Accurate、Consistent、Testable等工程事項，那些就交由V&V進行即可，但所有交付給客戶的Products都必須先經由QA簽署(完成7.的peer review之後)，再由PM簽署之後呈送CM核可，即可交付客戶，QA簽署之前必須先經由其他的Interfaced Group先簽署，因此在QAP中要敘述QA Group所必須檢視的CSCI products (要簽署文件)、review meeting (要參加會議)、V&V products and testing (要監控測試的執行)；

9.QA、CM、V&V、Mechanization Group都是針對同一個專案的Products，(a)Mechanization Group可依據IEEE-1063、830、1016、1471等Standards撰寫文件、(b)CM可依據IEEE-828進行Baseline、Change management、Audit等變更管理與稽核、(c)V&V可依據IEEE-1012進行V&V，以確定工程產物的Correct、Complete、Accurate、Consistent、Testable、(d)QA依據IEEE-730、PMP所敘述的Standards、Organization assets的Procedures進行與Products/Process相關之各項應執行Standards/Procedures的assurance，所以品質的第一道防線是專案訂定有完整的Standards，組織內有正確且嚴謹的Procedures，且工程人員願意配合執行(通常是公司不願意做)、第二道防線是由Verification確認工程的正確性(通常由老闆直接決定)、第三道防線是QA確定所有事項確實有依規定執行，（前三者屬於預防性(Prevention)）、第四道防線是藉由Validation找出defect(屬於disclose，但問題已存在，通常是想辦法遮蓋掉）。

非常謝謝眾老師的回覆,啟發我從IEEE/EIA 12207做解讀.
V&V以及SQA皆屬於Life Cycle中的品質管理的項目,其中SQA是為了品質保證而實行的Audit活動(Audit內容包含process & product),而V&V則是驗證與確認每一個Process的產出是符合前項活動的需求及最終使用者的需要.
CM則屬於Life Cycle中與文件及變更的基準(baseline)及版本識別的管理.
不知道我這樣的解讀是否正確?

SQA的"A"不論是CMMI的PPQA，ISO/IEC 12207 6.3節QA，IEEE軟體標準範圍裡的SQA，所指的是Assurance(保證，亦即在「提供信心」)，而不是Audit(稽核)。分辨這兩這件事是很重要的，否則的話，在面對ISO/IEC 12207 中的6.7節Audit時，還是會搞混；在IEEE Std 1028軟體審查標準裡，稽核也是其收攏的一個工作程序，這會讓人覺得"Audit"又等於"Review"，問題就變得更加複雜了。

在SQA裡，很明確的，是要為管理者或相關利害關係人提供信心--產品及產出產品的過程是符合要求、符合規範、忠於計畫與過程的。這與CMMI所提到PPQA是在為幕僚人員與管理者提供過程與相關工作產品客觀的深刻理解(insight)並無二致。

當你要進行SQA的時候，你會去選擇一些能獲得專案或產品客觀見地的產品與過程，並以這些項目為SQA工作的標的物。這些產品、工作產品與過程，會包括計畫、工作程序、工作產出，還有「驗證、確認、聯合審查、稽核與問題解決」的結果(參閱ISO/IEC 12207，第6.3節品質保證過程)。

我認為不要把SQA全等於稽核，是因為在SQA規劃與執行上，我們會因為SQA工作標的物的不同，而採用不同的方法、工具與程序，而Audit就是作法之一。

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

本府某單位目前有個兩千多萬元的資訊軟體系統委外案，承包商是在該應用領域非常知名的國內廠商，本案依合約應於去年底完工驗收，但是到今年三月才開始進行測試，測試期間因不斷有修改，常常造成甲程式設計師蓋掉乙程式設計師已修改完成的程式，不甚其擾，後來監造顧問要求廠商做好程式軟體的建構管理，情況才稍有改善。

本案一直進行了六個多月的測試後，廠商終於最近報請驗收，但因為原來的需求規格書(SRS)及設計說明書(SDD)已經和目前的程式不一致，監造顧問要求廠商必需重寫，但該廠商幾位主要程式設計師都已先後離職(原先該廠商總經理特助曾誇口說他們是國內歷史悠久的領導廠商，員工幾乎很少離職，請我們放心)，實在令人擔心這個系統的未來維護性。

此外，承包商說這個系統已經測試修改了六個多月，驗收時應該可以不需要再測了，但監造顧問卻認為這六個多月來的修改不斷，又沒有一致的文件，軟體建構管理做的也不理想，僅做迴歸測試也不可行，建議整個系統應再重新測試一遍，請問有沒有其它的解決辦法呢 ?

To Terry,

去年一開始就應該做的事，到了今年眼見專案問題百出，才想辦法補救，看樣子要按合約驗收是很難的，如果真能驗收，貴府的政風單位應該好好查一查人員的疏失狀況喔。

需求規格書及設計說明書和現在的程式不一樣，這是很大的問題吧。到底現在的程式是否符合需求呢？如果是，這代表一開始貴府的承辦人員就沒有盡到責任，沒有把委外的需求開發與管理的工作做好，然後監造顧問也沒有盡到責任，未能在一開始就依照其專業從事監造工作，而且更有可能的是太容易對於品質的問題妥協吧。

事實上，你的問題要能徹底解決，是要重新從現有的程式開始，把所有的程式一支一支用清單列出來，然後往前與設計說明書對照，看缺了那些沒有描述，把它們都補回設計說明書，再從設計說明書對照回需求規格書，把這些需求補回來，然後再對照回合約，我預計完成這樣的工作，可能至少要再三個月吧。如果不這樣做的話，還想要談CM是沒有意義的。