基本目標
SQA目標 2: 客觀地驗證軟體項目產品和工作是否遵循恰當的標準、步驟和需求。
目標 3: 將軟體質量保證工作及結果通知給相關組別和個人。
目標 4: 高級管理層接觸到在項目內部不能解決的不符合類問題。
由來
我們知道，國外很多的大公司，QA的職責就是測試（主要是系統測試），比如IBM、CA、PeopleSoft等。其實在最初，幾乎所有的公司都是這樣的。後來，由於缺乏有效的項目計畫和項目管理，留給系統測試的時間很少（註：我以前做的一個項目，項目經理就明確告訴我系統測試就1天，沒得商量）。另外，需求變化太快，沒有完整的需求文檔，測試人員就只能根據自己的想像來測試。這樣一來，測試就很難保障產品的質量，事先預防的QA職能就應運而生。
事先預防其實是借鑑了TQM的思想，而且也符合軟體工程“缺陷越早發現越早修改越經濟”的原則。這些思想的淵源還可以追溯到中國古代的典故中，比如曲突徙薪、扁鵲論醫術等。特別是扁鵲論醫術這個典故，我偶然在國外的一篇文章中看到了（後來在林銳的文章中也看到了），常感嘆我們國人連祖先的思想文化遺產都丟的差不多了。
現狀
sqa缺乏信任和支持只是一個方面，QA工作本身就很具挑戰性。它要求QA具有軟體工程的知識、軟體開發的知識、行業背景的知識、數理統計的知識、項目管理的知識、質量管理的知識等等。
我們常常遇到這樣的問題，改進到一定程度就很難突破，感覺心有餘而力不足了，就開始鬱悶了。後來通過學習、培訓、交流，思想和技能得到升華，又發現了木桶中最短的那塊，然後又開始改進，然後又遇到了玻璃天花板，然後……就這樣處於鬱悶的循環中。
假使我們掌握了所有的知識，能突破所有的玻璃天花板，那是不是QA就可以一帆風順了。答案是否定的。QA角色定義本身就有很大的局限性。QA充當的是過程警察的角色，無論是否有意義，都專橫地強制過程的執行，容易在項目組中造成敵對的關係，受到排擠，而且這種警察的姿態也破壞了團隊精神。如此一來，QA工作還需要的是人際關係技能，就如我以前寫的《質量平衡》和《QA應該獨立於項目組嗎？》一樣，藝術化地處理這種關係。
未來
從某種程度上說，獨立的QA審查機制是瀑布模型的產物。隨著現代軟體開發技術的演變，螺鏇模型和疊代模型的興起，QA機制正在悄然發生變化。這種變化就是從獨立專職的QA向貫穿過程的兼職QA演變。在CMMI模型中，這種兼職的QA也是被允許的。為什麼會發生這種改變呢？無論是XP、RUP還是其它先進的方法論，都是先產生架構，然後再增量開發，直到完成。這種模式中，需求和設計缺陷在各個疊代周期被所儘早發現和修復，質量也內建於架構和過程中，項目的成本和進度也得到保障。
到那時，是不是獨立的QA就不復存在了呢？有些成熟度較低的企業還是需要??。
理論探索
1、過程的認識
我們都知道一個項目的主要內容是：成本、進度、質量；良好的項目管理就是綜合三方面的因素，平衡三方面的目標，最終依照目標完成任務。項目的這三個方面是相互制約和影響的，有時對這三方面的平衡策略甚至成為一個企業級的要求，決定了企業的行為，我們知道 IBM的軟體是以質量為最重要目標的，而微軟的“足夠好的軟體”策略更是耳熟能詳，這些質量目標其實立足於企業的戰略目標。所以用於進行質量保證的SQA工作也應當立足於企業的戰略目標，從這個角度思考SQA，形成對SQA的理論認識。
軟體界已經達成共識的：影響軟體項目進度、成本、質量的因素主要是 “人、過程、技術”。首先要明確的是這三個因素中，人是第一位的。
現在許多實施 CMM的人員沉溺於CMM的理論過於強調“過程”，這是很危險的傾向。這個思想傾向在國外受到了猛烈抨擊，從某種意義上各種敏捷過程方法的提出就是對強調過程的一種反思。 “XP”中的一個思想“人比過程更重要” 是值得我們思考的。我個人的意見在進行過程改進中堅持“以人為本”，強調過程和人的和諧。
根據現代軟體工程對眾多失敗項目的調查，發現管理是項目失敗的主要原因。這個事實的重要性在於說明了 “要保證項目不失敗，我們應當更加關注管理”，注意這個事實沒有說明另外一個問題“良好的管理可以保證項目的成功”。現在很多人基於一種粗糙的邏輯，從一個事實反推到的這個結論，在邏輯上是錯誤的，這種錯誤形成了更加錯誤的做法，這點在SQA的理解上是體現較深。
如果我們考證一下歷史的沿革，應當更加容易理解 CMM的本質。CMM首先是作為一個“評估標準”出現的，主要評估的是美國國防部供應商保證質量的能力。CMM關注的軟體生產有如下特點：
（1）質量重要
（2）規模較大
這是 CMM產生的原因。它引入了“全面質量管理”的思想，尤其側重了“全面質量管理”中的“過程方法”，並且引入了“統計過程控制”的方法。可以說這兩個思想是CMM背後的基礎。
上面這些內容形成了我對軟體過程地位、價值的基本理解；在這個基礎上我們可以引申討論 SQA。
2、生產線的隱喻
如果將一個軟體生產類比於一個工廠的生產。那么生產線就是過程，產品按照生產線的規定過程進行生產。 SQA的職責就是保證過程的執行，也就是保證生產線的正常執行。
抽象出管理體系模型的如下，這個模型說明了一個過程體系至少應當包含 “決策、執行、反饋”三個重要方面。
QA的職責就是確保過程的有效執行，監督項目按照過程進行項目活動；它不負責監管產品的質量，不負責向管理層提供項目的情況，不負責代表管理層進行管理，只是代表管理層來保證過程的執行。
3、SQA和其他工作的組合
在很多企業中，將 SQA的工作和QC、SEPG、組織級的項目管理者的工作混合在一起了，有時甚至更加注重其他方面的工作而沒有做好SQA的本職工作。
根據 hjhza 的意見“中國現在基本有三種QA（按照工作重點不同來分）：一是過程改進型，一是配置管理型，一是測試型”。我個人認為是因為SQA工作和其他不同工作組合在一起形成的。
下面根據本人經驗對它們之間的關係進行一個說明。
4、QA和QC
兩者基本職責
QC：檢驗產品的質量，保證產品符合客戶的需求；是產品質量檢查者；
QA：審計過程的質量，保證過程被正確執行；是過程質量審計者；
注意區別檢查和審計的不同
檢查：就是我們常說的找茬，是挑毛病的；
審計：來確認項目按照要求進行的證據；仔細看看CMM中各個KPA中SQA的檢查採用的術語大量用到了“證實”，審計的內容主要是過程的；對照CMM看一下項目經理和高級管理者的審查內容，他們更加關注具體內容。
對照上面的管理體系模型，QC進行質量控制，向管理層反饋質量信息；QA則確保QC按照過程進行質量控制活動，按照過程將檢查結果向管理層匯報。這就是QA和QC工作的關在這樣的分工原則下， QA只要檢查項目按照過程進行了某項活動沒有，產出了某個產品沒有；而QC來檢查產品是否符合質量要求。
如果企業原來具有 QC人員並且QA人員配備不足，可以先確定由QC兼任QA工作。但是只能是暫時的，獨立的QA人員應當具備，因為QC工作也是要遵循過程要求的，也是要被審計過程的，這種混合情況，難以保證QC工作的過程質量。
5、QA和SEPG
兩者基本職責
SEPG：制定過程，實施過程改進；
QA： 確保過程被正確執行
SEPG應當提供過程上的指導，幫助項目組制定項目過程，幫助項目組進行策劃；從而幫助項目組有效的工作，有效的執行過程。如果項目和QA對過程的理解發生爭持，SEPG作為最終仲裁者。為了進行有效過程改進，SEPG必須分析項目的數據。
QA本也要進行過程規範，那么所有QA中最有經驗、最有能力的QA可以參加SEPG，但是要注意這兩者的區別。
如果企業的 SEPG人員具有較為深厚的開發背景，可以兼任SQA工作，這樣利於過程的不斷改進；但是由於立法、執法集於一身也容易造成SQA過於強勢，影響項目的獨立性。
管理過程比較成熟的企業，因為企業的文化和管理機制已經健全， SQA職責範圍的工作較少，往往只是針對具體項目制定明確重點的SQA計畫，這樣SQA的審計工作會大大減少，從而可以同時審計較多項目。工的細緻化，管理體系的複雜化，往往需要專職的 SEPG人員，這些人員要求了解企業的所有管理過程和運作情況，在這個基礎上才能統籌全局的進行過程改進，這時了解全局的SQA人員就是專職SEPG的主要人選；這些SQA人員將逐漸的轉化為SEPG人員，並且更加了解管理知識，而SQA工作漸漸成為他們的兼職工作。
這種情況在許多 CMM5企業比較多見，往往有時看不見SQA人員在項目組出現或者很少出現，這種SEPG和SQA的融合特別有利於組織的過程改進工作。SEPG確定過程改進內容，SQA計畫重點反映這些改進內容，從保證有效的改進，特別有利於達到CMM5的要求。從這個角度，國外的SQA人員為什麼高薪就不難理解了，也決定了當前中國SQA人員比較被輕視的原因；因為管理過程還不完善，我們的SQA人員還沒有產生這么大的價值嘛！
6、QA和組織級的監督管理
有的企業為了更好的監督管理項目，建立了一個角色，我取名為 “組織級的監督管理者”，他們的職責是對所有項目進行統一的跟蹤、監督、適當的管理，來保證管理層對所有項目的可視性、可管理性。
為了有效管理項目， “組織級的監督管理者”必須分析項目的數據。
他們的職責對照上圖的模型，就是執行 “反饋”職能。
QA本身不進行反饋工作，最多對過程執行情況的信息進行反饋。
SQA職責最好不要和“組織級的項目管理者”的職責混合在一起，否則容易出現SAQ困境：一方面SQA不能準確定位自己的工作，另一方面過程執行者對SQA人員抱有較大戒心。
如果建立了較好的管理過程，那么就會增強項目的可視性，從而保證企業對所有項目的較好管理；而 QA來確保這個管理過程的運行。
工作內容
SQA是軟體過程中的獨立審查活動，它的主要工作內容就是驗證質量管理軟體的開發、產品信息等是否符合可行的過程、規範、計畫和標準等。包括了開發支持活動，質量保證計畫，過程評審，評審結果報告，不符合問題處理等等內容。1.計畫（項目前）
針對具體項目制定SQA計畫，確保項目組正確執行過程。制定SQA計畫應當注意一些問題。首先要做到有重點，依據企業目標以及項目情況確定審計的重點；第二是要明確審計內容，審計哪些活動、哪些產品；第三是明確審計方式，確定怎樣進行審計；最後要明確審計結果報告的規則以及審計的結果報告給誰。
2.審計（軟體開發周期中）
依據SQA計畫進行SQA審計工作，按照規則發布審計結果報告。注意審計一定要有項目組人員陪同，不能搞突然襲擊。雙方要開誠布公，坦誠相對。審計的內容要注意是否按照過程要求執行了相應活動，是否按照過程要求產生了相應產品。
3.問題跟蹤
在質量管理軟體開發期間，對於評審中發現的問題和項目日常工作中發現的問題，SQA要進行跟蹤，直至解決。對於在項目組內可以既解決的問題就在項目組內解決，對於在項目組內部無法解決的問題，或是在項目組中跟催多次也沒有得到解決的問題，可以利用其獨立匯報的渠道報告給高層經理。
4.配置管理
SQA要對項目過程中的配置管理工作是否按照項目最初定製的配置管理計畫進行監督，其中包括配置管理人員是否定期進行該方面的工作、是否所有人得到的都是開發過程產品的有效版本。這裡的過程產品包括項目過程中產生的代碼和文檔。
5.人的管理
現如今軟體界已經達成一個共識，即影響軟體項目進度、成本、質量的因素主要是“人、過程、技術”。首先要明確的是這三個因素中，人是第一位的。質量管理部的人員專門負責質量管理工作，項目管理委員會對質量管理工作進行規劃指導，質量管理人員對項目和委員會負責。可以定期舉辦內部、外部的交流活動，增長經驗。
素質
過程為中心：應當站在過程的角度來考慮問題，只要保證了過程， QA就盡到了責任。
服務精神：為項目組服務，幫助項目組確保正確執行過程
了解過程：深刻了解企業的工程，並具有一定的過程管理理論知識
了解開發：對開發工作的基本情況了解，能夠理解項目的活動
溝通技巧：善於溝通，能夠營造良好的氣氛，避免審計活動成為一種找茬活動。
活動
軟體質量保證（SQA）是一種套用於整個軟體過程的活動，它包含：
1、一種質量管理方法
2、有效的軟體工程技術（方法和工具）
3、在整個軟體過程中採用的正式技術評審
4、一種多層次的測試策略
5、對軟體文檔及其修改的控制
6、保證軟體遵從軟體開發標準
7、度量和報告機制
SQA與兩種不同的參與者相關 —— 做技術工作的軟體工程師和負責質量保證的計畫、監督、記錄、分析及報告工作的SQA小組 。
軟體工程師通過採用可靠的技術方法和措施，進行正式的技術評審，執行計畫周密的軟體測試來考慮質量問題，並完成軟體質量保證和質量控制活動。
SQA小組的職責是輔助軟體工程小組得到高質量的最終產品。SQA小組完成:
（1）為項目準備SQA計畫。該計畫在制定項目規定項目計畫時確定，由所有感興趣的相關部門評審。
·需要進行的審計和評審；
·項目可採用的標準；
·錯誤報告和跟蹤的規程；
·由SQA小組產生的文檔；
·向軟體項目組提供的反饋數量。
（2）參與開發項目的軟體過程描述。評審過程描述以保證該過程與組織政策，內部軟體標準，外界標準以及項目計畫的其他部分相符。
（3）評審各項軟體工程活動，對其是否符合定義好的軟體過程進行核實。記錄、跟蹤與過程的偏差。
（4）審計指定的軟體工作產品，對其是否符合事先定義好的需求進行核實。對產品進行評審，識別、記錄和跟蹤出現的偏差；對是否已經改正進行核實；定期將工作結果向項目管理者報告。
（5）確保軟體工作及產品中的偏差已記錄在案，並根據預定的規程進行處理。
（6）記錄所有不符合的部分並報告給高級領導者。
技術評審
正式技術評審是一種由軟體工程師和其他人進行的軟體質量保障活動。
1. 目標：
(1) 發現功能、邏輯或實現的錯誤
(2) 證實經過評審的軟體的確滿足需求
(3) 保證軟體的表示符合預定義的標準
(4) 得到一種一致的方式開發的軟體
(5) 使項目更易管理
2、評審會議
3-5人參加，不超過2小時，由評審主席、評審者和生產者參加，必須做出下列決定中的一個 :
（1）工作產品可不可以不經修改而被接受；
（2）由於嚴重錯誤而否決工作產品；
（3）暫時接受工作產品。
3、評審總結報告、回答
評審什麼？由誰評審？結論是什麼？
評審總結報告是項目歷史記錄的一部分，標識產品中存在問題的區域，作為行政條目檢查表以指導生產者進行改正。
4、評審指導原則
（1）評審產品，而不是評審生產者。注意客氣地指出錯誤，氣氛輕鬆。
（2）不要離題，限制爭論。有異議的問題不要爭論但要記錄在案。
（3）對各個問題都發表見解。問題解決應該放到評審會議之後進行。
（4）為每個要評審的工作產品建立一個檢查表。應為分析、設計、編碼、測試文檔都建立檢查表。
（5）分配資源和時間。應該將評審作為軟體工程
質量保證
1、對所有錯誤進行分類統計
IES 規約不完整或規格說明錯
MCC 未理解用戶意圖
IDS 故意偏離規格說明
VPS 違背編程標準
EDR 數據表示有錯
ICI構件接口不一致
EDL 設計邏輯有錯
IET 測試不完全或有錯
IID 不準確或不完整的文檔
PLT 設計的程式設計語言翻譯錯
HCI 不清晰或不一致的人機界面
MIS雜項錯誤
按嚴重，一般和微小級別統計各類錯誤的次數所占百分比，以及所有錯誤的數量及百分比。例如，建立一張類似如下的表格。
然後考慮“重要少數”的錯誤指標，提出改進意見。
2、根據軟體過程中的每個步驟計算錯誤指標。
Ei=第i發現的錯誤總數
Si=嚴重錯誤數
M=一般錯誤數
Ti=微小錯誤數
PS=第i步的產品規模(LOC，設計陳述，文檔頁數)
Ws，Wm，Wt分別是嚴重，一般，微小錯誤的加權因子,推薦取值，Ws=10，Wm=3，Wt=1
軟體工程在過程的每一步中，計算各階段的階段指標
PIi=Ws（Si / Ei）+Wm（Mi / Ei）+Wt（Ti / Ei）
錯誤指標
Ei=∑（i×PIi）/ PS
=（PI1 + 2PI2 + 3PI3 + … + i*PIi）/ PS
錯誤指標與上面表格中收集的信息相結合可以得出軟體質量整體改進指標。七、質量保證與檢驗
確保每個開發過程的質量，防止把軟體差錯傳播到下一個過程，因此，檢驗的目的有兩個：
1．切實搞好開發階段的管理，檢查各開發階段的質量保證。
2．預先防止軟體差錯給用戶造成損失。
檢驗的類型有:
1．供貨檢驗：對委託外單位承擔開發作業，而後買進或轉讓的構成軟體產品的部件，規格說明，半成品或產品的檢查。
2．中間檢驗 / 階段評審
目的是為了判斷是否可進入下階段進行後續開發，避免將差錯傳播到後續工作中。
3．驗收檢驗：
確認產品是否已達到可以進行產品檢驗的質量要求。
4．產品檢驗：
判定向用戶提供的軟體產品是否達到令人滿意的程度。
項目內容
1．需求分析
需求分析→功能設計→實施計畫
檢查：開發目的；目標值；開發量；所需資源；各階段的產品作業內容及開發體制的合理性。
2．設計
結構設計→數據設計→過程設計
檢查：產品的計畫量與實際量；評審量；差錯數；評審方法，出錯導因及處理情況，階段結束的判斷標準。
3．實現
程式編制→單元測試→集成測試→確認測試.檢查內容除上述外，加測試環境及測試用例設計方法。
4．驗收
說明書檢查；程式檢查。
1．3質量保證實施軟體質量評價標準。
1．質量需求準則：著眼點是是否滿足用戶的要求
2．質量設計準則：開發者在設計實現時是否按軟體需求保證了質量
3．質量度量準則：為質量度量規定了一些檢查項目:
精密度量：根據質量度量準則進行詳細度量五個實施步驟
1．Target：以用戶需求和開發任務為依據，對質量需求準則，質量設計準則的質量特性設定質量目標進行評價。
2．Plan：設定適合於待開發軟體的評測檢查項目，一般設定20—30個。
3．DO：在開發標準和質量評價準則的指導下，製作高質量的規格說明書和程式。
4．Check：以Plan階段設定的質量評價準則進行評價，算出得分，以質量圖的形成表示出來，比較評價結果的質量得分和質量目標看其是否合格。
5．Action：對評價發現的問題進行改進活動，重複Plan到Action的過程直到開發項目完成。
1．4 軟體可靠性
可靠性統計定義：
在給定的環境和給定的時間間隔內，按設計要求成功運行程式的機率。
二、軟體可靠性的主要指標
MTBF —— 平均故障間隔時間
MTTF —— 平均故障時間
MTTR —— 平均修復時間
MTBF = MTTF + MTTR
軟體可用性是指在某個給定時間點程式能夠按照需求執行的機率。
可用性 = MTTF /（MTTF+MTTR）×100%
1．5 ISO9000 質量標準
ISO9000標準被很多國家採用，包括歐盟的所有成員，加拿大、墨西哥、美國、澳大利亞、紐西蘭和太平洋區域。為了註冊成為ISO9000中包含的質量保證系統模型中的一??者仔細檢查，查看其標準的符合性以及操作的有效性。成功註冊之後，這一公司將收到由審計者所代表的註冊實體頒發的證書。此後，每半年進行一次檢查性審計。
ISO9001是套用於軟體工程質量保證標準。這一標準中包含了高效的質量保證系統必須體現的20條需求。因為ISO9001標準，適用於所有的工程行業，因此，為幫助解釋該標準在軟體過程中的使用而專門開發了一個ISO指南的子集ISO9000—3。
ISO9001描述的需求涉及到管理責任，質量系統，契約評審，設計控制，文檔和數據控制，產品標識和跟蹤，過程和控制，審查和測試，糾正和預防性動作，質量控制記錄，內部質量審計，培訓，服務以及統計技術的主題。
