如何實施軟體品質保證

軟體品質保證（即SQA——Software Quality Assurance），是CMM2級中的一個關鍵過程域,它是貫穿整個軟體過程的第三方獨立審查活動，出現在大多數關鍵過程域的檢查與驗證的公用特性中，在整個軟體開發過程中充當重要角色。從CMM2級中包含的6個關鍵過程域來看，無論是需求管理、軟體專案計劃、軟體項目跟蹤與監控，還是軟體子合約管理、軟體組態管理，都不同程度地存在於我們現在進行中的軟體項目開發過程中，對於它們的瞭解我們已經不再陌生，只有SQA這個關鍵過程域，是在我們準備以CMM2級要求的關鍵過程域為基礎進行軟體流程改善前未接觸過的。在很多軟體企業中還沒有與之相對應的人員和工作方法，整套關注軟體開發過程的軟體品質保證體系還沒有建立起來。所以，在企業以CMM2級關鍵過程域為參考進行軟體流程改善時，SQA往往是一個痛點，直接涉及到組織圖的變化。

實施SQA的目的

軟體品質保證的目標是以獨立審查方式，從第三方的角度監視軟體開發工作單位的執行,就軟體項目是否正遵循已制定的計劃、標準和規程給開發人員和管理層提供反映產品和過程品質的資訊和資料，提高項目透明度，同時輔助軟體工程組取得高品質的軟體產品。主要包括以下四個方面：

● 通過監視軟體開發過程來保證產品品質;

● 保證開發出來的軟體和軟體開發過程符合相應標準與規程；

● 保證軟體產品、軟體過程中存在的不符合問題得到處理,必要時將問題反映給進階管理者；

● 確保項目組制定的計劃、標準和規程適合項目組需要，同時滿足評審和審計需要;

除了以上四點之外，我們還希望SQA能作為軟體工程流程群組（SEPG）在項目組中的延伸，能夠收集項目中好的實施方法和發現實施不利的原因，為修改企業內部軟體開發整體規範提供依據，為其他項目組的開發過程實施提供先進方法和範例。

對SQA人員的素質要求

1. SQA人員(有時簡稱SQA)要有很強的溝通能力。從實施SQA的目的中可以看出，SQA不在項目中，是獨立於軟體項目的第三方，但他要瞭解項目的開發過程和進度，捕捉到項目中不符合要求的問題，這就要求SQA能夠深入項目，和軟體開發經理以及項目組中的開發人員保持很好的溝通，這樣才能及時獲得真實的項目情況。

2. SQA要熟悉軟體開發過程。作為SQA，既然要確保項目組制定的計劃、標準和規程，要符合項目組要求，那麼SQA首先自己就要瞭解軟體項目開發過程，以及企業內部已經有的開發過程規範。

3. SQA本身要有很強的計劃性。SQA一方面要監督軟體項目組編寫計劃，另一方面SQA自身的工作也要有計劃，並且能夠按照計劃開展工作。

4. SQA要能應對繁雜的工作。作為SQA，在跟蹤項目進行過程的時候要對項目組的很多工作產品進行審計，而且會參與項目組中的多種活動。同時一個SQA還有可能會面對多重專案組，所以任務相對繁雜細碎，這就要求SQA在處理這些事物的時候要耐心細緻。

5. SQA要客觀，有責任心。作為第三方對項目過程進行監督，SQA要能保持自己的客觀性，不能一味討好專案經理，也不能成為項目組中的憲兵，否則會影響工作的開展。對於項目組中多次協調解決不了的問題，能夠向項目的高層經理進言，完成SQA的使命。

以上五點是作為SQA應該具備的基本素質，除此之外，一個好的SQA還應該在軟體開發過程中作為開發人員或測試人員參與過一個或多個環節，這樣他們才能在過程監督中比較準確地抓住重點，同時他們的意見和提出的解決辦法也會更貼近項目組，容易被項目組接受。

SQA人員的組成

軟體企業中的SQA人員既可以由全職人員擔任，也可以由企業內具有相關素質、經過SQA培訓的人員兼職擔任。由此組成的SQA小組可能是一個真正的物理上存在的獨立部門，也可以是一個邏輯上存在的平台。但不管是真正的獨立部門還是邏輯上的平台，它都需要有一個靈魂人物——SQA小組組長，來組織SQA小組的日常活動。

在給一個項目組分配負責監督其項目過程的SQA時，一定要注意一點：就是該項目的SQA不能是該項目組的開發人員、組態管理人員或測試人員，一個項目的SQA除了監控項目過程，完成SQA相關工作以外，不應該參與項目組的其他實質性工作，否則他會與項目組捆綁在一起，很難保持客觀性。

SQA工作的內容

SQA的工作內容主要包括以下六類：

1. 與SQA計劃直接相關的工作：SQA在項目早期要根據專案計劃制定與其對應的SQA計劃，定義出各階段的檢查重點，標識出檢查、審計的工作產品對象，以及在每個階段SQA的輸出產品。定義越詳細，對於SQA今後的工作的指導性就會越強，同時也便於軟體專案經理和SQA組長對其工作的監督。編寫完SQA計劃後要組織SQA計劃的評審，並形成評審報告，把通過評審的SQA計劃發送給軟體專案經理、項目開發人員和所有相關人員。

2. 參與項目的階段性評審和審計：在SQA計劃中通常已經根據專案計劃定義了與項目階段相應的階段檢查，包括參加項目在本階段的評審和對其階段產品的審計。對於階段產品的審計通常是檢查其階段產品是否按計劃按規程輸出並內容完整，這裡的規程包括企業內部統一的規程也包括項目組內自己定義的規程。但是SQA對於階段產品內容的正確性一般不負責任檢查，對於內容的正確性通常交由項目中的評審來完成。SQA參與評審是從保證評審過程有效性方面入手，如參與評審的人是否具備一定資格、是否規定的人員都參見了評審、評審中對被評審的對象的每個部分都進行了評審、並給出了明確的結論等等。

3. 對項目日常活動與規程的符合性進行檢查: 這部分的工作內容是SQA的日常工作內容。由於SQA獨立於項目組，如果只是參與階段性的檢查和審計很難及時反映項目組的工作過程，所以SQA也要在兩個階段點之間設定若干小的跟蹤點，來監督項目的進行情況，以便能及時反映出項目組中存在的問題，並對其進行追蹤。如果只在階段點進行檢查和審計，即便發現了問題也難免過於滯後，不符合儘早發現問題、把問題控制在最小的範圍之內的整體目標。

4. 對組態管理工作的檢查和審計：SQA要對項目過程中的組態管理工作是否按照項目最初制定的組態管理計划進行監督，包括組態管理人員是否定期進行該方面的工作、是否所有人得到的都是開發過程產品的有效版本。

這裡的過程產品包括項目過程中產生的代碼和文檔。

5. 跟蹤問題的解決情況: 對於評審中發現的問題和項目日常工作中發現的問題，SQA要進行跟蹤，直至解決。對於在項目組內可以解決的問題就在項目組內部解決，對於在項目組內部無法解決的問題，或是在項目組中跟催多次也沒有得到解決的問題，可以利用其獨立彙報的渠道報告給高層經理。

6. 收集新方法，提供流程改善的依據：此類工作很難具體定義在SQA的計劃當中，但是SQA有機會直接接觸很多項目組，對於項目組在開發管理過程中的優點和缺點都能準確的獲得第一手資料。他們有機會瞭解項目組中管理好的地方是如何做的，採用了什麼有效方法，在SQA小組的活動中與其他SQA共用。這樣這些好的實施執行個體就可以被傳播到更多的項目組中。對於企業內過程規範定義的不準確或是不方便的地方，軟體項目組也可以通過SQA小組反映到軟體工程流程群組，便於下一步對規程進行修改和完善。

SQA與幾類角色間的關係

一個企業內的部門設定可能會各有不同，但是很多角色設定是相同的，從一個項目的SQA出發，我們可以把SQA與其他相關角色的關係表示為:

以示只說明SQA與高層經理、項目組和其他相關組之間的關係，並不是以上幾個角色之間所有關係的描述，所以即便項目組會直接向高層經理彙報，但與SQA無直接關係，在圖中就沒有表現出來。

SQA工作中常見的幾個問題

1. 最初給項目組配置SQA人員的時候，SQA的價值不被認可

因為是新工作的初次開展，已經習慣了自己管理項目，向高層經理彙報的項目組難免會有抵觸情緒。要從兩個方面解決這個問題：一方面，從組織的角度，要明確SQA的角色及其合法性; 另一方面，SQA也要以其專業的工作贏得項目組認可，為項目組增加價值。

2. 一個全職的SQA可以同時兼任多少個項目的SQA工作

對於不同的項目規模和組織管理方式，這個問題會有不同的答案，根據實施中的一些經驗總結，通常在第一次實施時，承擔一個20人左右的項目組的SQA工作需要佔用一個人30%左右的工作量，隨著SQA的成熟，這個比例會降低到15%。對於一個10人以內的項目組，SQA需要投入其10%左右的工作量。當然，項目越大SQA的投入就越多。

3. SQA與項目組的關係難處理

對於SQA與項目組的關係，應該遵循以下兩條原則: 要在過程方面成為項目組的嚴師，有錯必糾，但不能有錯全報；要做項目組的朋友，但不能對項目組包庇縱容。

4. 項目組有了SQA，可是需求文檔和設計文檔的品質還是不高

對不起，這不是SQA的直接工作範圍。提高需求和設計的品質，要從人員培訓和嚴格評審入手，讓有經驗有資格的人來完成需求和設計文檔。SQA只能從規程符合方面進行監督。

總之，在軟體企業中建立SQA體系，是軟體專案管理由人治到法治的一個必經階段，也是軟體企業以CMM模型為參考，進行軟體流程改善中一個不可缺少的部分。軟體企業只要真正建立了SQA規範，培養了專業的SQA人員就會真正從中體會到它的好處。