轉的
小白進階之SQA軟體質量保證工程師工作職責與素質要求
一、 SQA 工作職責與素質要求
二、實施 SQA 的目的
三、對 SQA 人員的素質要求
四、SQA 人員的組成
五、SQA 工作的內容
六、SQA 與幾類角色間的關係
七、SQA 工作中常見的幾個問題
叮嘟！小白進階，每天掌握一點常見問題小常識，寫篇部落格分享一下。
軟體質量保證（即 SQA——Software Quality Assurance ），是 CMM2 級中的一個關鍵過程域 , 它是貫穿整個軟體過程的第三方獨立審查活動，出現在大多數關鍵過程域的檢查與驗證的公共特性中，在整個軟體開發過程中充當重要角色。
從 CMM2 級中包含的 6 個關鍵過程域來看，無論是需求管理、軟體專案計劃、軟體專案跟蹤與監控，還是軟體子合同管理、軟體配置管理，都不同程度地存在於我們現在正在進行的軟體專案開發過程中，對於它們的瞭解我們已經不再陌生，只有 SQA 這個關鍵過程域，是在我們準備以 CMM2 級要求的關鍵過程域為基礎進行軟體過程改進前未接觸過的。在很多軟體企業中還沒有與之相對應的人員和工作方法，整套關注軟體開發過程的軟體質量保證體系還沒有建立起來。所以，在企業以 CMM2 級關鍵過程域為參考進行軟體過程改進時， SQA 往往是一個難點，直接涉及到組織結構的變化。
軟體質量保證的目標是以獨立審查方式，從第三方的角度監控軟體開發任務的執行 , 就軟體專案是否正遵循已制定的計劃、標準和規程給開發人員和管理層提供反映產品和過程質量的資訊和資料，提高專案透明度，同時輔助軟體工程組取得高質量的軟體產品。主要包括以下四個方面：
● 透過監控軟體開發過程來保證產品質量 ;
● 保證開發出來的軟體和軟體開發過程符合相應標準與規程；
● 保證軟體產品、軟體過程中存在的不符合問題得到處理 , 必要時將問題反映給高階管理者；
● 確保專案組制定的計劃、標準和規程適合專案組需要，同時滿足評審和審計需要 ;
除了以上四點之外，我們還希望 SQA 能作為軟體工程過程小組（ SEPG ）在專案組中的延伸，能夠收集專案中好的實施方法和發現實施不利的原因，為修改企業內部軟體開發整體規範提供依據，為其他專案組的開發過程實施提供先進方法和樣例。
SQA 人員 ( 有時簡稱 SQA) 要有很強的溝通能力。從實施 SQA 的目的中可以看出， SQA 不在專案中，是獨立於軟體專案的第三方，但他要了解專案的開發過程和進度，捕捉到專案中不符合要求的問題，這就要求 SQA 能夠深入專案，和軟體開發經理以及專案組中的開發人員保持很好的溝通，這樣才能及時獲得真實的專案情況。
SQA 要熟悉軟體開發過程。作為 SQA ，既然要確保專案組制定的計劃、標準和規程，要符合專案組要求，那麼 SQA 首先自己就要了解軟體專案開發過程，以及企業內部已經有的開發過程規範。
SQA 本身要有很強的計劃性。 SQA 一方面要監督軟體專案組編寫計劃，另一方面 SQA 自身的工作也要有計劃，並且能夠按照計劃開展工作。
SQA 要能應對繁雜的工作。作為 SQA ，在跟蹤專案進行過程的時候要對專案組的很多工作產品進行審計，而且會參與專案組中的多種活動。同時一個 SQA 還有可能會面對多個專案組，所以任務相對繁雜細碎，這就要求 SQA 在處理這些事物的時候要耐心細緻。
SQA 要客觀，有責任心。作為第三方對專案過程進行監督， SQA 要能保持自己的客觀性，不能一味討好專案經理，也不能成為專案組中的憲兵，否則會影響工作的開展。對於專案組中多次協調解決不了的問題，能夠向專案的高層經理進言，完成 SQA 的使命。
以上五點是作為 SQA 應該具備的基本素質，除此之外，一個好的 SQA 還應該在軟體開發過程中作為開發人員或測試人員參與過一個或多個環節，這樣他們才能在過程監督中比較準確地抓住重點，同時他們的意見和提出的解決辦法也會更貼近專案組，容易被專案組接受。
軟體企業中的 SQA 人員既可以由全職人員擔任，也可以由企業內具有相關素質、經過 SQA 培訓的人員兼職擔任。由此組成的 SQA 小組可能是一個真正的物理上存在的獨立部門，也可以是一個邏輯上存在的平臺。但不管是真正的獨立部門還是邏輯上的平臺，它都需要有一個靈魂人物 ——SQA 小組組長，來組織 SQA 小組的日常活動。
在給一個專案組分配負責監督其專案過程的 SQA 時，一定要注意一點：就是該專案的 SQA 不能是該專案組的開發人員、配置管理人員或測試人員，一個專案的 SQA 除了監控專案過程，完成 SQA 相關工作以外，不應該參與專案組的其他實質性工作，否則他會與專案組捆綁在一起，很難保持客觀性。
SQA 的工作內容主要包括以下六類：
與 SQA 計劃直接相關的工作： SQA 在專案早期要根據專案計劃制定與其對應的 SQA 計劃，定義出各階段的檢查重點，標識出檢查、審計的工作產品物件，以及在每個階段 SQA 的輸出產品。定義越詳細，對於 SQA 今後的工作的指導性就會越強，同時也便於軟體專案經理和 SQA 組長對其工作的監督。編寫完 SQA 計劃後要組織 SQA 計劃的評審，並形成評審報告，把透過評審的 SQA 計劃傳送給軟體專案經理、專案開發人員和所有相關人員。
參與專案的階段性評審和審計：在 SQA 計劃中通常已經根據專案計劃定義了與專案階段相應的階段檢查，包括參加專案在本階段的評審和對其階段產品的審計。對於階段產品的審計通常是檢查其階段產品是否按計劃按規程輸出並內容完整，這裡的規程包括企業內部統一的規程也包括專案組內自己定義的規程。但是 SQA 對於階段產品內容的正確性一般不負責任檢查，對於內容的正確性通常交由專案中的評審來完成。 SQA 參與評審是從保證評審過程有效性方面入手，如參與評審的人是否具備一定資格、是否規定的人員都參見了評審、評審中對被評審的物件的每個部分都進行了評審、並給出了明確的結論等等。
對專案日常活動與規程的符合性進行檢查 : 這部分的工作內容是 SQA 的日常工作內容。由於 SQA 獨立於專案組，如果只是參與階段性的檢查和審計很難及時反映專案組的工作過程，所以 SQA 也要在兩個階段點之間設定若干小的跟蹤點，來監督專案的進行情況，以便能及時反映出專案組中存在的問題，並對其進行追蹤。如果只在階段點進行檢查和審計，即便發現了問題也難免過於滯後，不符合儘早發現問題、把問題控制在最小的範圍之內的整體目標。
對配置管理工作的檢查和審計： SQA 要對專案過程中的配置管理工作是否按照專案最初制定的配置管理計劃進行監督，包括配置管理人員是否定期進行該方面的工作、是否所有人得到的都是開發過程產品的有效版本。
這裡的過程產品包括專案過程中產生的程式碼和文件。
跟蹤問題的解決情況 : 對於評審中發現的問題和專案日常工作中發現的問題， SQA 要進行跟蹤，直至解決。對於在專案組內可以解決的問題就在專案組內部解決，對於在專案組內部無法解決的問題，或是在專案組中跟催多次也沒有得到解決的問題，可以利用其獨立彙報的渠道報告給高層經理。
收集新方法，提供過程改進的依據：此類工作很難具體定義在 SQA 的計劃當中，但是 SQA 有機會直接接觸很多專案組，對於專案組在開發管理過程中的優點和缺點都能準確的獲得第一手資料。他們有機會了解專案組中管理好的地方是如何做的，採用了什麼有效的方法，在 SQA 小組的活動中與其他 SQA 共享。這樣這些好的實施例項就可以被傳播到更多的專案組中。對於企業內過程規範定義的不準確或是不方便的地方，軟體專案組也可以透過 SQA 小組反映到軟體工程過程小組，便於下一步對規程進行修改和完善。
一個企業內的部門設定可能會各有不同，但是很多角色設定是相同的，從一個專案的 SQA 出發，我們可以把 SQA 與其他相關角色的關係表示為下圖 :
以上圖示只說明 SQA 與高層經理、專案組和其他相關組之間的關係，並不是以上幾個角色之間所有關係的描述，所以即便專案組會直接向高層經理彙報，但與 SQA 無直接關係，在圖中就沒有表現出來。
最初給專案組配置 SQA 人員的時候， SQA 的價值不被認可 。因為是新工作的初次開展，已經習慣了自己管理專案，向高層經理彙報的專案組難免會有牴觸情緒。
要從兩個方面解決這個問題：一方面，從組織的角度，要明確 SQA 的角色及其合法性 ; 另一方面， SQA 也要以其專業的工作贏得專案組認可，為專案組增加價值。
一個全職的 SQA 可以同時兼任多少個專案的 SQA 工作對於不同的專案規模和組織管理方式，這個問題會有不同的答案。根據實施中的一些經驗總結，通常在第一次實施時，承擔一個 20 人左右的專案組的 SQA 工作需要佔用一個人 30% 左右的工作量，隨著 SQA 的成熟，這個比例會降低到 15% 。對於一個 10 人以內的專案組， SQA 需要投入其 10% 左右的工作量。當然，專案越大 SQA 的投入就越多。
SQA 與專案組的關係難處理 。對於 SQA 與專案組的關係，應該遵循以下兩條原則 : 要在過程方面成為專案組的嚴師，有錯必糾，但不能有錯全報；要做專案組的朋友，但不能對專案組包庇縱容。
專案組有了 SQA ，可是需求文件和設計文件的質量還是不高 。
對不起，這不是 SQA 的直接工作範圍。提高需求和設計的質量，要從人員培訓和嚴格評審入手，讓有經驗有資格的人來完成需求和設計文件。 SQA 只能從規程符合方面進行監督。
總之，在軟體企業中建立 SQA 體系，是軟體專案管理由人治到法治的一個必經階段，也是軟體企業以 CMM 模型為參考，進行軟體過程改進中一個不可缺少的部分。軟體企業只要真正建立了 SQA 規範，培養了專業的 SQA 人員就會真正從中體會到它的好處。
小結！
學海無涯，學無止境。
讓我們一點一滴積累吧，相信水滴石穿，總歸功夫不負有心人。
轉的
小白進階之SQA軟體質量保證工程師工作職責與素質要求
一、 SQA 工作職責與素質要求
二、實施 SQA 的目的
三、對 SQA 人員的素質要求
四、SQA 人員的組成
五、SQA 工作的內容
六、SQA 與幾類角色間的關係
七、SQA 工作中常見的幾個問題
叮嘟！小白進階，每天掌握一點常見問題小常識，寫篇部落格分享一下。
一、 SQA 工作職責與素質要求
軟體質量保證（即 SQA——Software Quality Assurance ），是 CMM2 級中的一個關鍵過程域 , 它是貫穿整個軟體過程的第三方獨立審查活動，出現在大多數關鍵過程域的檢查與驗證的公共特性中，在整個軟體開發過程中充當重要角色。
從 CMM2 級中包含的 6 個關鍵過程域來看，無論是需求管理、軟體專案計劃、軟體專案跟蹤與監控，還是軟體子合同管理、軟體配置管理，都不同程度地存在於我們現在正在進行的軟體專案開發過程中，對於它們的瞭解我們已經不再陌生，只有 SQA 這個關鍵過程域，是在我們準備以 CMM2 級要求的關鍵過程域為基礎進行軟體過程改進前未接觸過的。在很多軟體企業中還沒有與之相對應的人員和工作方法，整套關注軟體開發過程的軟體質量保證體系還沒有建立起來。所以，在企業以 CMM2 級關鍵過程域為參考進行軟體過程改進時， SQA 往往是一個難點，直接涉及到組織結構的變化。
二、實施 SQA 的目的
軟體質量保證的目標是以獨立審查方式，從第三方的角度監控軟體開發任務的執行 , 就軟體專案是否正遵循已制定的計劃、標準和規程給開發人員和管理層提供反映產品和過程質量的資訊和資料，提高專案透明度，同時輔助軟體工程組取得高質量的軟體產品。主要包括以下四個方面：
● 透過監控軟體開發過程來保證產品質量 ;
● 保證開發出來的軟體和軟體開發過程符合相應標準與規程；
● 保證軟體產品、軟體過程中存在的不符合問題得到處理 , 必要時將問題反映給高階管理者；
● 確保專案組制定的計劃、標準和規程適合專案組需要，同時滿足評審和審計需要 ;
除了以上四點之外，我們還希望 SQA 能作為軟體工程過程小組（ SEPG ）在專案組中的延伸，能夠收集專案中好的實施方法和發現實施不利的原因，為修改企業內部軟體開發整體規範提供依據，為其他專案組的開發過程實施提供先進方法和樣例。
三、對 SQA 人員的素質要求
SQA 人員 ( 有時簡稱 SQA) 要有很強的溝通能力。從實施 SQA 的目的中可以看出， SQA 不在專案中，是獨立於軟體專案的第三方，但他要了解專案的開發過程和進度，捕捉到專案中不符合要求的問題，這就要求 SQA 能夠深入專案，和軟體開發經理以及專案組中的開發人員保持很好的溝通，這樣才能及時獲得真實的專案情況。
SQA 要熟悉軟體開發過程。作為 SQA ，既然要確保專案組制定的計劃、標準和規程，要符合專案組要求，那麼 SQA 首先自己就要了解軟體專案開發過程，以及企業內部已經有的開發過程規範。
SQA 本身要有很強的計劃性。 SQA 一方面要監督軟體專案組編寫計劃，另一方面 SQA 自身的工作也要有計劃，並且能夠按照計劃開展工作。
SQA 要能應對繁雜的工作。作為 SQA ，在跟蹤專案進行過程的時候要對專案組的很多工作產品進行審計，而且會參與專案組中的多種活動。同時一個 SQA 還有可能會面對多個專案組，所以任務相對繁雜細碎，這就要求 SQA 在處理這些事物的時候要耐心細緻。
SQA 要客觀，有責任心。作為第三方對專案過程進行監督， SQA 要能保持自己的客觀性，不能一味討好專案經理，也不能成為專案組中的憲兵，否則會影響工作的開展。對於專案組中多次協調解決不了的問題，能夠向專案的高層經理進言，完成 SQA 的使命。
以上五點是作為 SQA 應該具備的基本素質，除此之外，一個好的 SQA 還應該在軟體開發過程中作為開發人員或測試人員參與過一個或多個環節，這樣他們才能在過程監督中比較準確地抓住重點，同時他們的意見和提出的解決辦法也會更貼近專案組，容易被專案組接受。
四、SQA 人員的組成
軟體企業中的 SQA 人員既可以由全職人員擔任，也可以由企業內具有相關素質、經過 SQA 培訓的人員兼職擔任。由此組成的 SQA 小組可能是一個真正的物理上存在的獨立部門，也可以是一個邏輯上存在的平臺。但不管是真正的獨立部門還是邏輯上的平臺，它都需要有一個靈魂人物 ——SQA 小組組長，來組織 SQA 小組的日常活動。
在給一個專案組分配負責監督其專案過程的 SQA 時，一定要注意一點：就是該專案的 SQA 不能是該專案組的開發人員、配置管理人員或測試人員，一個專案的 SQA 除了監控專案過程，完成 SQA 相關工作以外，不應該參與專案組的其他實質性工作，否則他會與專案組捆綁在一起，很難保持客觀性。
五、SQA 工作的內容
SQA 的工作內容主要包括以下六類：
與 SQA 計劃直接相關的工作： SQA 在專案早期要根據專案計劃制定與其對應的 SQA 計劃，定義出各階段的檢查重點，標識出檢查、審計的工作產品物件，以及在每個階段 SQA 的輸出產品。定義越詳細，對於 SQA 今後的工作的指導性就會越強，同時也便於軟體專案經理和 SQA 組長對其工作的監督。編寫完 SQA 計劃後要組織 SQA 計劃的評審，並形成評審報告，把透過評審的 SQA 計劃傳送給軟體專案經理、專案開發人員和所有相關人員。
參與專案的階段性評審和審計：在 SQA 計劃中通常已經根據專案計劃定義了與專案階段相應的階段檢查，包括參加專案在本階段的評審和對其階段產品的審計。對於階段產品的審計通常是檢查其階段產品是否按計劃按規程輸出並內容完整，這裡的規程包括企業內部統一的規程也包括專案組內自己定義的規程。但是 SQA 對於階段產品內容的正確性一般不負責任檢查，對於內容的正確性通常交由專案中的評審來完成。 SQA 參與評審是從保證評審過程有效性方面入手，如參與評審的人是否具備一定資格、是否規定的人員都參見了評審、評審中對被評審的物件的每個部分都進行了評審、並給出了明確的結論等等。
對專案日常活動與規程的符合性進行檢查 : 這部分的工作內容是 SQA 的日常工作內容。由於 SQA 獨立於專案組，如果只是參與階段性的檢查和審計很難及時反映專案組的工作過程，所以 SQA 也要在兩個階段點之間設定若干小的跟蹤點，來監督專案的進行情況，以便能及時反映出專案組中存在的問題，並對其進行追蹤。如果只在階段點進行檢查和審計，即便發現了問題也難免過於滯後，不符合儘早發現問題、把問題控制在最小的範圍之內的整體目標。
對配置管理工作的檢查和審計： SQA 要對專案過程中的配置管理工作是否按照專案最初制定的配置管理計劃進行監督，包括配置管理人員是否定期進行該方面的工作、是否所有人得到的都是開發過程產品的有效版本。
這裡的過程產品包括專案過程中產生的程式碼和文件。
跟蹤問題的解決情況 : 對於評審中發現的問題和專案日常工作中發現的問題， SQA 要進行跟蹤，直至解決。對於在專案組內可以解決的問題就在專案組內部解決，對於在專案組內部無法解決的問題，或是在專案組中跟催多次也沒有得到解決的問題，可以利用其獨立彙報的渠道報告給高層經理。
收集新方法，提供過程改進的依據：此類工作很難具體定義在 SQA 的計劃當中，但是 SQA 有機會直接接觸很多專案組，對於專案組在開發管理過程中的優點和缺點都能準確的獲得第一手資料。他們有機會了解專案組中管理好的地方是如何做的，採用了什麼有效的方法，在 SQA 小組的活動中與其他 SQA 共享。這樣這些好的實施例項就可以被傳播到更多的專案組中。對於企業內過程規範定義的不準確或是不方便的地方，軟體專案組也可以透過 SQA 小組反映到軟體工程過程小組，便於下一步對規程進行修改和完善。
六、SQA 與幾類角色間的關係
一個企業內的部門設定可能會各有不同，但是很多角色設定是相同的，從一個專案的 SQA 出發，我們可以把 SQA 與其他相關角色的關係表示為下圖 :
以上圖示只說明 SQA 與高層經理、專案組和其他相關組之間的關係，並不是以上幾個角色之間所有關係的描述，所以即便專案組會直接向高層經理彙報，但與 SQA 無直接關係，在圖中就沒有表現出來。
七、SQA 工作中常見的幾個問題
最初給專案組配置 SQA 人員的時候， SQA 的價值不被認可 。因為是新工作的初次開展，已經習慣了自己管理專案，向高層經理彙報的專案組難免會有牴觸情緒。
要從兩個方面解決這個問題：一方面，從組織的角度，要明確 SQA 的角色及其合法性 ; 另一方面， SQA 也要以其專業的工作贏得專案組認可，為專案組增加價值。
一個全職的 SQA 可以同時兼任多少個專案的 SQA 工作對於不同的專案規模和組織管理方式，這個問題會有不同的答案。根據實施中的一些經驗總結，通常在第一次實施時，承擔一個 20 人左右的專案組的 SQA 工作需要佔用一個人 30% 左右的工作量，隨著 SQA 的成熟，這個比例會降低到 15% 。對於一個 10 人以內的專案組， SQA 需要投入其 10% 左右的工作量。當然，專案越大 SQA 的投入就越多。
SQA 與專案組的關係難處理 。對於 SQA 與專案組的關係，應該遵循以下兩條原則 : 要在過程方面成為專案組的嚴師，有錯必糾，但不能有錯全報；要做專案組的朋友，但不能對專案組包庇縱容。
專案組有了 SQA ，可是需求文件和設計文件的質量還是不高 。
對不起，這不是 SQA 的直接工作範圍。提高需求和設計的質量，要從人員培訓和嚴格評審入手，讓有經驗有資格的人來完成需求和設計文件。 SQA 只能從規程符合方面進行監督。
總之，在軟體企業中建立 SQA 體系，是軟體專案管理由人治到法治的一個必經階段，也是軟體企業以 CMM 模型為參考，進行軟體過程改進中一個不可缺少的部分。軟體企業只要真正建立了 SQA 規範，培養了專業的 SQA 人員就會真正從中體會到它的好處。
小結！
學海無涯，學無止境。
讓我們一點一滴積累吧，相信水滴石穿，總歸功夫不負有心人。