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