軟件產品的質量定義始終都是滿足要求和適合使用，高質量和高等級是有區別的。軟件質量目標應該來源于商業目標驅動，商業目標決定了軟件的價值。提高軟件質量的目標仍然是為了盈利和創造更大的效益，而不是創造完美無缺的產品。
軟件產品質量不是靠
測試和評審出來的，而是靠設計出來的。關注軟件項目中的好質量成本和壞質量成本可以宏觀的看到項目軟件
質量管理的水平。對于軟件項目COQ一般在35%-55%，而壞質量成本一般在8-15%，這也說明我們要盡量減少返工，爭取第一次就把事情做對。
1.軟件的質量屬性和質量要素
PMBOK中質量的定義是符合要求和適合使用。CMM對質量的定義是一個系統，組件或過程符合客戶或用戶的要求或期望的程度。因此可以講質量更多不是研發者說的，而是用戶的最終感受。
通過類比，我們這樣理解軟件質量：軟件質量是許多質量屬性的綜合體現，各種質量屬性反映了軟件質量的方方面面。人們通過改善軟件的各種質量屬性，從而提高軟件的整體質量（否則無從下手）。
軟件的質量屬性很多，如正確性、精確性，健壯性、可靠性、容錯性、性能、易用性、安全性、可擴展性、可復用性、兼容性、可移植性、可測試性、可維護性、靈活性等。這些質量屬性又可以分為功能性和非功能性兩大類。
功能性質量要素:正確性，健壯性，可靠性
非功能性質量因素：性能，易用性，安全性，可擴展性，兼容性，可移植性
a.正確性:第一重要，機器不會欺騙人，軟件運行錯誤都是人為造成的。
b.健壯性:包括容錯能力和恢復能力，開發過程中應該充分考慮各種異常和邊界。
c.可靠性:可靠性是指在一定的環境下，在給定的時間內，系統不發生故障的概率。
d.性能：性能通常是指軟件的“時間-空間”效率，而不僅是指軟件的運行速度。(性能問題解決根本還是算法和程序的優化，而不是期待硬件的更高配置)
e.易用性:易用性是指用戶使用軟件的容易程度。(界面友好僅僅是一方面，還包括人機工程很多內容)
f.安全性:安全性是指防止系統被非法入侵的能力
g.擴展性:反映了軟件應對變化的能力
h.兼容性:對硬件的兼容，對軟件的兼容
非功能性需求是軟件質量重要組成，是架構設計和軟件產品化的重要考慮，但往往容易被忽視。特別是在開發通用性的產品的時候，非功能性質量要素必須要考慮全面。
什么是質量要素，應該理解為能夠提高用戶滿意度和提高產品核心競爭力和價值的質量屬性。如果某些質量屬性并不能產生顯著的經濟效益，我們可以忽略它們，把精力用在對經濟效益貢獻最大的質量要素上。簡而言之，只有質量要素才值得開發人員下功夫去改善。
2.商業目標決定質量目標
重視軟件質量是應該的，但是“質量越高越好”并不是普適的真理。只有極少數軟件應該追求“零缺陷”，對絕大多數軟件而言，商業目標決定了質量目標，而不該把質量目標凌駕于商業目標之上。
企業的根本目標是為了獲取盡可能多的利潤，而不是生產完美無缺的產品。如果企業銷售出去的軟件的質量比較差，輕則挨罵，重則被退貨甚至被索賠，因此為了提高用戶對產品的滿意度，企業必須提高產品的質量。但是企業不可能為了追求完美的質量而不惜一切代價，當企業為提高質量所付出的代價超過銷售收益時，這個產品已經沒有商業價值了，還不如不開發。
企業必須權衡質量、效率和成本，產品質量太低了或者太高了，都不利于企業獲取利潤。企業理想的質量目標不是“零缺陷”，而是恰好讓廣大用戶滿意，并且將提高質量所付出的代價控制在預算之內。
3.質量保證能夠保證質量嗎
軟件質量保證（Quality Assurance）的目的是為管理者提供有關軟件過程和產品的適當的可視性。它包括評審和審核軟件產品及其活動，以驗證其是否遵守既定的規程和標準，并向有關負責人匯報評審和審核的結果。
簡而言之，質量保證活動就是檢查軟件項目的“
工作過程和工作成果”是否符合既定的規范。如此簡單的活動為什么被冠以“質量保證”這等份量的術語呢？沒有歷史典故，經我考究，猜想是源于一個天真的假設：
過程質量與產品質量存在某種程度的因果關系，通常“好的過程”產生“好的產品”，而“差的過程”將產生“差的產品”。假設企業已經制定了軟件過程規范，如果質量保證人員發現某些項目的“工作過程以及工作成果”不符合既定的規范，那么馬上可以斷定產品存在缺陷。反之，如果質量保證人員沒有發現不符合既定規范的東西，那么也可以斷定產品是合格的。
符合既定規范的東西并不意味著質量一定合格，僅靠規范無法識別出產品中可能存在的大量缺陷.
4.全面軟件質量管理模型
提高軟件質量最好的辦法是：在開發過程中有效地防止工作成果產生缺陷，將高質量內建于開發過程之中。主要措施是“不斷地提高技術水平，不斷地提高規范化水平”，其實就是練內功，通稱為“軟件過程改進”。
其次方法是當工作成果剛剛產生時馬上進行質量檢查，及時找出并消除工作成果中的缺陷。這種方式效果比較好，人們一般都能學會。最常用的方法是技術評審、
軟件測試和過程檢查，已經被企業廣泛采用并取得了成效。
最差的是在軟件交付之前，沒有及時消除缺陷。當軟件交付給用戶后，用著用著就出錯了，趕緊請開發者來補救。可笑的是，當軟件系統在用戶那里出故障了，那些現場補救成功的人倒成了英雄，好心用戶甚至還寄來感謝信。
誰對軟件質量負責？是全員負責。任何與軟件開發、管理工作相關的人員都對質量產生影響，都要對質量負責。所以人們不要把質量問題全部推出質量人員或測試人員。
誰對軟件質量負最大的責任？誰的權利越大，他所負的質量責任就越大。質量人員是成天與質量打交道的人，但他個人并不對產品質量產生最大的影響，所以也不負最大的責任。
質量人員的主要職責：
1.負責制定質量計劃（很重要但是工作量比較少）；
2.負責過程檢查（類似于CMM中的質量保證），約占個人工作量的20%；
3.參與技術評審，約占個人工作量的30%；
4.參與軟件測試，約占個人工作量的30%；
5.參與軟件過程改進（面向整個機構），約占個人工作量的20%；
質量管理計劃的主要內容（模板見word文件）：
1. 質量要素分析
2. 質量目標
3. 人員與職責
4. 過程檢查計劃
5. 技術評審計劃
6. 軟件測試計劃
7. 缺陷跟蹤工具
8. 審批意見
5.技術評審
技術評審（Technical Review, TR）的目的是盡早地發現工作成果中的缺陷，并幫助開發人員及時消除缺陷，從而有效地提高產品的質量。技術評審最初是由IBM公司為了提高軟件質量和提高程序員生產率而倡導的。技術評審方法已經被業界廣泛采用并收到了很好的效果，它被普遍認為是軟件開發的最佳實踐之一。
技術評審的主要好處有：
1.通過消除工作成果的缺陷而提高產品的質量；
2.技術評審可以在任何開發階段執行，不必等到軟件可以運行之際，越早消除缺陷就越能降低開發成本；
3.開發人員能夠及時地得到同行專家的幫助和指導，無疑會加深對工作成果的理解，更好地預防缺陷，一定程度上提高了開發生產率。
技術評審有兩種基本類型：
1.正式技術評審FTR。FTR比較嚴格，需要舉行評審會議多。
2.非正式技術評審ITR。ITR的形式比較靈活，通常在同伴之間開展，不必舉行評審會
技術評審和軟件測試的目的都是為了消除軟件的缺陷，兩者的主要區別是：
1.前者無需運行軟件，評審人員和作者把工作成果擺放在桌面上討論；
2.而后者一定要運行軟件來查找缺陷。技術評審在軟件測試之前執行，尤其是在需求開發和系統設計階段。
相比而言，軟件測試的工作量通常比技術評審的大，發現的缺陷也更多。在制定質量計劃的時候，已經確定了本項目的主要測試活動、時間和負責人，之后再考慮軟件測試的詳細計劃和測試用例。
如果機構沒有專職的軟件測試人員的話，那么開發人員可以兼職做測試工作。當項目開發到后期，過程檢查和技術評審都已經沒有多少意義了，開發小組急需有人幫助他們測試軟件，如果質量人員參與軟件測試，對開發小組而言簡直就是“雪中送炭”。
強調：質量人員一定要參與軟件測試（大約占其工作量的30％左右），只有這樣他才能深入地了解軟件的質量問題，而且給予開發小組強有力地幫助。
CMM和ISO9001所述的軟件質量保證，實質就是過程檢查，即檢查軟件項目的“工作過程和工作成果”是否符合既定的規范。
“過程檢查”這個詞雖然沒有質量保證那么動聽，但是其含義直接明了，不會讓人誤解。為了避免人們誤以為“質量保證”能夠“保證質量”，我提議用“過程檢查”取代質量保證這個術語。
雖然本章批判了“質量保證”的浮夸，但是并沒有全盤否定質量保證的好處。過程檢查對提高軟件質量是有幫助的，只是它的好處沒有象質量保證鼓吹的那么好而已。
符合規范的工作成果不見得就是高質量的，但是明顯不符合規范的工作成果十有八九是質量不合格的。例如版本控制檢查,再例如，機構制定了重要工作成果的文檔模板（例如需求規格說明書、設計報告等），要求開發人員寫的文檔盡可能符合模板。如果質量人員發現開發人員寫的文檔與機構的模板差異非常大，那么就要搞清楚究竟是模板不合適？還是開發人員偷工減料？
過程檢查的要點是：找出明顯不符合規范的工作過程和工作成果，及時指導開發人員糾正問題，切勿吹毛求疵或者在無關痛癢的地方查來查去。
不少機構的質量人員并沒有真正理解過程檢查的意義，老是對照規范，查找錯別字、標點符號、排版格式等問題，迷失了方向，這樣只有疲勞沒有功勞，而且讓開發人員很厭煩。
對于中小型項目而言，過程檢查工作由質量人員一個人負責就夠了，約占其20％的工作量，讓質量人員抽出更多的時間從事技術評審和軟件測試工作。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters